Re: [SIESTA-L] URGENT (supercell for bulk)
Dear Catrina, Mind that you have periodical boundary conditions so your unit cell is repeated infinite number of times in all directions. So, you only need to construct a supercell if you want to break the symmetry (i.e. introduce defects). Or if you want to imitate zero boundary conditions (i.e. for isolated molecules, surfaces etc) by constructing a large supercell with a vacuum layer. if you calculate just an ideal bulk crystal, making supercell does not change anything at all because of periodic boundary conditions! so you just waste the computation time if you do it. regards, Yurko 2008/11/25 catrina desport [EMAIL PROTECTED]: Dear Andrei Postnikov, I am sorry if my words were confusing. Actually, it is not the matter of imitating at all. I just wanted to know if having supercell for some systems like bulk hexagonal helps to get better answers. I didn't enclose their article to keep it from judgements, but in a presentation I found from the work they did, I saw the below lines: Bulk ... (hexagonal system) SIESTA: TM pseudopotential, ... basis, ... Ry mesh cutoff, LDA Piezoelectric constant Berry Phase: e33=... C/m2 Our O(N) method: e33=... C/m2 6×6×2 supercell Again, I insist, it is not the matter of imitating at all, just wanted to know if there's a helpful method to get reasonable parameters for hexagonal systems, especially those which are abit unstable. I hope to have your valuable response. Regards, Catrina From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: SIESTA-L@listserv.uam.es Sent: Tuesday, November 25, 2008 6:32:02 PM Subject: Re: [SIESTA-L] URGENT (supercell for bulk) To all respected siesta users: Considering an article on a hexagonal lattice, written by authors who have worked with siesta, I have encountered that they have used 6x6x2 supercell for their bulk system !!! Dear Catrina: if it is really supercell used in their calculation and not just superc: Internal auxiliary supercell message, then they should have had a good reason for doing it (usually, modeling a point defect, ) and not just bulk? I need to know how they have done it to generate the appropriate supercell I'd guess, rather by hand or by using the SuperCell block (once, and then exporting the generated coordinates in the input file) for better optimization for my system as well. I wonder how can supercell help in better optimization of your system? Please do guide me, it is very urgent for me. This is difficult for two reasons: you do not explain what you want to do, and refer to other peoples' work which you apparently want to imitate, without giving any details or reference. Best regards Andrei Postnikov -- Yurko (aka Yuriy, Iurii, Jurij etc) Natanzon PhD Student Henryk Niewodniczan`ski Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Krako`w, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Converting .vps to .psf
Dear Carsten, I guess the only way to convert is to generate the pseudopotential from scratch using atom program. The cutoff radii as well as other parameters you will find in the beginning of the .vps file. regards, Yurko 2008/10/31 Carsten Rostgaard [EMAIL PROTECTED]: Hi I have some old well tested .vps pseudopotential files. I would like to keep using these, but we are changing computers, and the binary files are not transferable. Is there any way I can convert my .vps files to the ASCII .psf version? With kind regards, Carsten Rostgaard -- Carsten Rostgaard Ph.D. Student, M.Sc.Eng (Applied Physics) CAMD, Department of Physics, Technical University of Denmark Room 221, Building 307, DTU, DK-2800 Kongens Lyngby, Denmark E-mail: [EMAIL PROTECTED] - Phone: +45 4525 3185 -- Yurko (aka Yuriy, Iurii, Jurij etc) Natanzon PhD Student Henryk Niewodniczan`ski Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Krako`w, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Comparing energy outputs between siesta and gaussian
Dear John,
One would not expect that total energy obtained by different
calculation methods (and different exchange-correlation functional!)
will be the same, thus such comparison has no physical sense. I'd
rather recommend to compare the measurable physical quantities, i.e.
lattice constants or bulk modulus, instead of total energy. Total
energy differences between different material phases are also
meaningful, not the total energy itself.
regards,
Yurko
2008/7/31 Russell, John Thomas [EMAIL PROTECTED]:
(Sorry if this is being received a second time. I have just been added to
this list and have had difficulty getting this message sent.)
I am very new to Siesta, and I just ran a test job for a single Lithium
atom. I compared the energy outputs with results that I got from single
point calculations from gaussian.
HF/STO-3G (Gaussian): -7.38 Hartrees (-200.38 eV)
B3LYP/6-31G* (Gaussian): -7.49 Hartrees (-203.813 eV)
But when I run Siesta I get -4.90 eV.
I would greatly appreciate it someone could explain the difference! I will
include the output energies from Siesta and input below.
Thanks for your help,
John
siesta: Final energy (eV):
siesta: Kinetic = 2.631848
siesta: Hartree = 1.428153
siesta:Ext. field = 0.00
siesta: Exch.-corr. = -3.172836
siesta: Ion-electron = -3.680688
siesta: Ion-ion = -2.101984
siesta: Ekinion = 0.00
siesta: Total = -4.895506
SystemName Lithium
SystemLabel Li
NumberOfAtoms 1
NumberOfSpecies 1
%block ChemicalSpeciesLabel
1 3 Li # Species index, atomic number, species label
%endblock ChemicalSpeciesLabel
AtomicCoordinatesFormat Ang
%block AtomicCoordinatesAndAtomicSpecies
0.000 0.000 0.000 1
%endblock AtomicCoordinatesAndAtomicSpecies
WriteMullikenPop 1
NetCharge 0
SaveRho .true.
The Pseudopotential for Lithium was generated with the following:
#
# Pseudopotential generation for Lithium
# pg: simple generation
#
pg Lithium
tm2 0.0 # PS flavor, logder R
n=Li c=car # Symbol, XC flavor,{ |r|s}
0.0 0.0 0.0 0.0 0.0 0.0
14 # norbs_core, norbs_valence
20 1.00 0.00 # 2s1
21 0.00 0.00 # 2p0
32 0.00 0.00 # 3d0
43 0.00 0.00 # 4d0
2.40 2.40 2.40 2.40 0.00 0.00
#
# Last line (above):
#rc(s) rc(p) rc(d) rc(f) rcore_flag rcore
#
#23456789012345678901234567890123456789012345678901234567890
--
Yurko (aka Yuriy, Iurii, Jurij etc) Natanzon
PhD Student
Henryk Niewodniczan`ski Institute of Nuclear Physics
Polish Academy of Sciences
ul. Radzikowskiego 152,
31-342 Krako`w, Poland
Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] rgarding Bulkmodulus
I'd recommend rather +/- 3% of the equilibrium volume. I've used this tool: http://www.fhi-berlin.mpg.de/th/fhi98md/toolkit/murn.tar It works well for noncubic lattices also. 2008/6/21 Sushil Auluck [EMAIL PROTECTED]: hi, bulk modulus is defined near the equilibrium volume. so calculate total energies around 15% of the eq. volume s.auluck -- ... Prof. Sushil Auluck Phone:+91-512-6797092/6148 Department of Physics +91-512-6798177(Home) Indian Institute of Technology Cell :+91-9305548667 Kanpur 208016 (UP) Fax :+91-512-6790914 India E-mail:[EMAIL PROTECTED] ...:[EMAIL PROTECTED] http://www.iitk.ac.in/phy/People/phy_facvis.html http://www.iitk.ac.in/phy/New01/profile_SA.html ... -- Yurko (aka Yuriy, Iurii, Jurij etc) Natanzon PhD Student Henryk Niewodniczan`ski Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Krako`w, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] bulk modulus
There is a link to the SIESTA Tutorials which may be helpful: http://www.uam.es/departamentos/ciencias/fismateriac/siesta/tutorials.html Tutorials contain both lecture notes and exercises (bulkmodulus calculation was done at the Tutorial in Lyon, at least). Bulk modulus calculation: You may calculate it from elastic constants using the relation between bulk modulus and elastic constants, or you may do series of calculation Total energy vs unit cell volume and fit it with Murgaghan equation. For details please follow this discussion thread: http://www.mail-archive.com/siesta-l@listserv.uam.es/msg01297.html 2008/6/10 zubaer [EMAIL PROTECTED]: No offense to anyone. To get an answer from the mailing list sometimes it requires quite a bit of time to search. Also information is found in sort of scattered ways in different places. It takes some expertise in using SIESTA to summarize those info as well. It would be great if SIESTA could provide a FAQ section. One example with detail description of how to find a, B, Ec, convergence of basis, mesh, band structure etc would have been nice. Thanks, -Zubaer On Tue, Jun 10, 2008 at 11:28 AM, Marcel Mohr [EMAIL PROTECTED] wrote: This was discussed at least 3 times in the last year. Cheers Marcel Hint: There is no switch in siesta for calculating the bulk modulus On Tue, 10 Jun 2008, madani samah wrote: Dear siesta users; Please can any body tell me how to compute the bulk modulus and what are the instructions to be included in .fdf file used for this aim. Thanks before _ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr -- Yurko (aka Yuriy, Iurii, Jurij etc) Natanzon PhD Student Henryk Niewodniczan`ski Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Krako`w, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Rejected postings
For sure this happens. But I've the notification turned on and see that my message was succesfully distributed despite the rejection. This is a kind of bug but you just ignore the rejection message because it's not rejected in fact. On 11/03/2008, R.C.Pasianot [EMAIL PROTECTED] wrote: Hello everybody, It's me again, with a (small) complaint :( . Each time I send a message to the list I get a rejected message notification from [EMAIL PROTECTED] saying I've sent the same message twice. Of course I didn't do that, so there must be something in my mail header that is confusing this dummy (does not happen with other lists I'm subscribed). Is this a known issue ?, how can I fix this missbehabiour ?. Thanks. Cheers, Roberto -- Yurko (aka Yuriy, Iurii, Jurij etc) Natanzon PhD Student Henryk Niewodniczan`ski Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Krako`w, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Parellelization overview
See, a colleague of mine says she's not seeing a (significant)
performance gain while running in parallel (10 or so nodes) with
respect to the serial case.
The performance is noticable when using larger supercells. The larger
cell is the bigger is the performance with respect to serial
calculation. I think, for 10 nodes you have to test a system with
several hundreds of atoms.
On 29/02/2008, R.C.Pasianot [EMAIL PROTECTED] wrote:
Hello Eduardo,
Thanks for your reply,
The short story,
My understanding is that Scalapack should put much more stress on the
communication hardware than parallelization over k. But apparently the
story below challenges this view.
More details,
See, a colleague of mine says she's not seeing a (significant)
performance gain while running in parallel (10 or so nodes) with
respect to the serial case. Apparently there's a hardware issue
with the cluster, but anyway, Wien2K guys are running their stuff
fairly OK (parallel over k).
So I suggested her to go with Siesta parallel over k, at the expense
of needing (quite a lot) more RAM (correct?). But the outcome was
about the same as before :( .
Best regards,
Roberto
snipped
I *think* they are sent back one by one, could you specify what are
you interested in?
3) seems that for k parallelization each process is self-sufficient
and therefore memory-hungry, while the Scalapack way essentially
divides memory needs. Correct ?.
With the parallel over K option each Hamiltonian is completely stored
in each processor
so there is no need for scalapack. When H is too big then it's
scattered in all the processors,
so you need to call scalapack.
. snipped
--
Yurko (aka Yuriy, Iurii, Jurij etc) Natanzon
PhD Student
Henryk Niewodniczan`ski Institute of Nuclear Physics
Polish Academy of Sciences
ul. Radzikowskiego 152,
31-342 Krako`w, Poland
Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Problem with optical properties
hmm, it seems the calculation has just reached its end, so this is not an error. But you've better attach the whole input and output. regards, Yurko On 29/10/2007, N H [EMAIL PROTECTED] wrote: Dear Siesta Users I trying to run optical calculations with SIESTA turning the flag Opticalcalculations on, but when the geometruy optimization get get over the program stop calculating sudently. It dont return any error message or else, but simply stop working at these ponti of calculation. the first lines with description of my compilling options in teh out are Siesta Version: siesta-2.0.1 Architecture : intel9-mkl8 Compiler flags: ifort -w -xW -O0 -mp1 ( I turn out optimizatiosn to check if it was a problem with them ) and the last lines before the program stop working are siesta: Pressure (static): siesta:SolidMolecule Units siesta: 0.00172457 0.00169353 Ry/Bohr**3 siesta: 0.15834379 0.15549400 eV/Ang**3 siesta: 253.69747052249.13154735 kBar Does any bady know what did I wrong?! Thanks in advance NH -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] UseStructFile
bipul, Maybe, this is a mistake in the User guide. For SIESTA 2.0 the correct syntax is MD.UseStructFile true regards, Yurko On 26/10/2007, bipul rakshit [EMAIL PROTECTED] wrote: hello siesta user, I use supercell block to generate supercells in fdf file and then i use UseStructFile .true. in order to make siesta to read the co-ordinates from file.STRUCT_IN but every time the siesta gives me an error you have to specify atomic co-ordinates But when i use MD.UseStructFile.true. siesta reads the co-ordinates.. But still in the user guide the above one is written.. I think UseStructFile .true. is in coorect way. Am i right Unlimited freedom, unlimited storage. Get it now -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] pseudopotential basis for Sulfur.
dear Jingbin, the problem is that atom program is very sensitive to the input file format. the number of spaces and position of all the parameter should not change. Try taking one of the sample input file from siesta/pseudo/atom/Tutorial and modify them for your purpose. On 28/09/2007, Jingbin Li [EMAIL PROTECTED] wrote: Dear Friend, I succeeded in produing the pseudopotential basis for Carbon atom under /Pseudo/atom/Tutorial directory and now I am trying to produce my own pseudopotential basis for Sulfur atom. I copy the parameters from atom_table.txt in dir /Pseudo/atom/Contrib. The S.tm2.inp file is like following, ## pg Sulfur Guess Ecut ~ 25Ryl=0,1,2 as local tm2 n=S c=ca 0.0 0.0 0.0 0.0 0.0 0.0 33 30 2.00 0.00 31 4.00 0.00 32 0.00 0.00 1.70 1.70 1.70 # And when I run sh ../pg.sh S.tm2.inp I got the following message cp: cannot stat `VPSOUT': No such file or directory cp: cannot stat `VPSFMT': No such file or directory == Output data in directory S.tm2 == Pseudopotential in S.tm2.vps and S.tm2.psf and I could not find the S.tm2.vps and S.tm2.psf files. How could I fix this ? Thanks Best, Jingbin -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] A naive question
Dear Zubaer, SIESTA is designed to work with thousands of atoms. If you attach your input and output files, it would be possible to help you. On 25/08/07, zubaer [EMAIL PROTECTED] wrote: Hi all, What is the maximum number of atoms I can simulate using SIESTA? I tried to work with 256 Ge atoms, but its not working. I am quite novice in using SIESTA. I would appreciate if anyone could help me. I am sorry if I am asking stupid question. Thanks, Zubaer -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
[SIESTA-L] failed to get XV file
Dear siesta users, Maybe a bit stupid question, but how to obtain Systemlabel.XV file needed by grid2cube utility? I set LongOutput, WriteCoorInitial and WriteCoorStep options to true but after calculation was finished, there was no XV file in the working directory. After searching through mailing list archives, I found I'm not the one who has faced this problem: there were reports, that SIESTA 2.0 doesn't produce XV for large systems. Can this issue somehow be solved? -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] siesta-output Description: Binary data
Re: [SIESTA-L] LAM SCALAPACK
Try removing -Bstatic flag, it causes such errors on many compilers On 02/06/07, Cherry Y. Yates [EMAIL PROTECTED] wrote: DEAR Developer, Do you have any suggestions for compiling a parallel version of SIESTA using LAM-MPI? I always got the following error messages: rdiag.o(.text+0x2a77): In function `rdiag_': : undefined reference to `blacs_gridinit__' libscalapack.a(descinit.o)(.text+0x54): In function `descinit_': : undefined reference to `blacs_gridinfo__' libscalapack.a(pxerbla.o)(.text+0x41): In function `pxerbla_': : undefined reference to `blacs_gridinfo__' libscalapack.a(pdpotrf.o)(.text+0x60): In function `pdpotrf_': : undefined reference to `blacs_gridinfo__' libscalapack.a(pbdtrnv.o)(.text+0xa1): In function `pbdtrnv_': : undefined reference to `blacs_gridinfo__' ... I compiled BLACS, SCALAPACK, and SIESTA using lam mpif77 -O3 -Bstatic. It looks like the names are not compatible. Anyone have a successful story with LAM? By the way, did anyone test the scaling of SIESTA for Gamma point only SCF calculations? Many thanks! Cherry Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Not enough memory in isolated molecule calcs
Dear Heribert, It seems Marcos reply hasn't gone to the list. I kindly ask you to repeat it here, I've faced the similar problem (and it should be actual for many users). best regards, Yurko On 17/05/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Marcos, Thanks for your comments! The large cells are needed to eliminate the influence of the electric potential of the neighboring molecules on the hyperpolarizabilities (hpols), which are very sensitive to electric fields. To determine the cell size we compute the hpols against cell size, until the hpols converge. Your suggestions will probably alleviate the memory problem a bit, but I'm not sure if even a parallel siesta would be able to cope with computing the hpols of a dipolar molecule much larger than benzene, say, a fullerene substituted with some porphyrins. What I wonder is if the memory allocation in Siesta can still be optimized. Obviously, Siesta takes advantage of the matrix sparsity during the calculation. But does it do so also for the memory allocation? I'm wondering, because if I run the benzene calculation with a cubic cell of 15 Ang length, Siesta allocates about 250 MB; with a cell of 25 Ang, it uses more than 1 GB, although the number of non-zero elements of the density matrix is exactly the same in both cases. Could it be that siesta allocates the memory just according to the worst case scenario of a density matrix non-zero everywhere, or is this line of thought too simplistic? Regards, Heribert mail2web.com – Enhanced email for the mobile individual based on Microsoft(r) Exchange - http://link.mail2web.com/Personal/EnhancedEmail -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] LDA pseudopotential for GGA calculations?
Dear Chenggang Zhou, You cannot use LDA pseudopotential in GGA calculations. However, you may try to generate GGA pseudo using the same cutoff radii and core/valence electrons as were used in LDA pseudo generation. Just replace ca by pb (or another GGA pseudo) in pseudopotential input file. In my case it gave a GGA pseudo which gives reasonable results for lattice constants and bulk modulus. However, I cannot guarantee that it will work in your case. best regards, Yurko On 06/05/07, Chenggang Zhou [EMAIL PROTECTED] wrote: Dear All, I want to calculate the Palladium system using GGA/PBE of siesta. I tried many times to generate GGA/PBE pseudopotentials of Pd using ATOM utility. But none of them can yield consistent cohesive energy of bulk Pd ( 3.89 eV) of experimental value. There is a well-tested LDA/CA pps at SIESTA official website. Can I just use that pps for GGA calculation? Or, could anybody kindly tell me how can I get a good GGA/PBE pps? Any suggestions or solutions would be greatly appreciated. Thanks in advance. C. Zhou -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] parallel run
Dear Saswata, Please search the list archives for the HOWTO by Sebastien Le Roux. Also my experience may help, but it is more related to pgf compiler on AMD machine: http://noddeat.livejournal.com/3633.html On 02/05/07, Saswata Bhattacharya [EMAIL PROTECTED] wrote: dear friends, Can anybody tell me how to install SIESTA parallely in a INTEL cluster?please write down the steps I need to do and the Libraries that I need to installif possible please attach the arch.make file regards, Saswata Check out what you're missing if you're not on Yahoo! Messenger -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Performing relaxation correctly
Dear Marcos, Thank you for your detailed explanation. But it seems to me that VariableCell=true calculations should give the same result as repeating several fized cell calculations. Do you take into account the value of stress tensor obtained in previous calculations for deciding the direction of the next spanning? And how much calculations do you perform on average to obtain a relaxed structure? On 01/05/07, Marcos Verissimo Alves [EMAIL PROTECTED] wrote: Hi Yurko, I guess the most correct way of doing this would be to do a search in all phase space of the possible parameters for the cell. In other words, you should relax atomic positions in fixed-cell calculations spanning the function E(a,b,c,alpha,beta,gamma), where E is the total energy, and a, b, c, alpha, beta and gamma are the crystallographic parameters (of course, you can always span a1, a2 and a3 in cartesian components, which is exactly the same). Thanks to shell scripting, this can be done in a relatively painless way. :) However, my personal experience with variable-cell calculations has shown me that many times you get results which are not **really** bad, as long as mesh cutoff, k-point sampling and atomic positions are not too far from the final result. As a matter of fact, sometimes I initially do a variable-cell calculation for small systems, to get an idea of where the equilibrium positions are, so I can make the spanning of the phase space around the right point. So I exaggerate a little bit on mesh cutoff (300-350 Ry, depending on the material) and k-point sampling, in order to see how good a variable-cell calculation could be. Sometimes this is even useful, like in the case of my calculations for graphene: The total energy was converged for a 9x9x1 Monkhorst-Pack grid, but I only got good structural parameters in the variable-cell calculation when I used 21x21x1 (!) for the unit cell. Of course, if you want to get exact Wyckoff positions at the end of your calculation, you will have to enforce symmetries in your systems, which siesta, unfortunately, does not, because it is meant to work with really large systems. Plane-wave programs like pwscf or abinit can take care of this kind of thing, but then there is no simple way to relate calculations made by those programs to siesta ones. I guess that, if you know some of the symmetries or physical constraints of the problem, it helps to rdeuce the computational load you would have if you did things by brute force. For example, if you know that your system has a fcc cell (like diamond), for example, then you don't really have to span the values of alpha, beta and gamma, just the lattice constant with fixed vactors. However, in a system with anisotropic responses along the different crystallographic directions, you will have to span the values of a, b and c and, possibly, also the angles. Take PbO, which is a layered system (not that it is very well-described by whatever flavor of xc you can think of, anyway). The interlayer interaction is weaker than the intralayer ones, so it will have different responses and you will have to take into account that the c axis will change differently than a and b, as a function of applied hydrostatic pressure. Thus, for PbO, either you perform variable-cell calculations or span the phase space of a, b and c. You will have to check for that kind of thing. Once again, the easiest thing to do is to write a shell script that will take into account the spanning of the phase space, which is not too difficult to do. Just a bit boring :) Hope this helps. Do zobaczenia :) Marcos Dear SIESTA users, I wonder how to perform the geometry relaxation in order to get the structure which really exists. If I turn VariableCell = true, I will have both atomic coordinates and unit cell parameters being relaxed at the same time, and finally get some optimized structure. I was told this is not a good way of relaxation, and I need to relax atomic coordinates first (VaribaleCell=false) and then relax a unit cell keeping coordinates fixed (by GeometryConstarints). but in this case I'm not able to get relaxed structure (pressure and stresses remain big). So I ask experienced users briefly how do you perform relaxation and whether you relax atomic coordinates and unit cell volume at the same time. -- Yurko Natanzon PhD Student Henryk Niewodnicza?ski Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] -- 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! -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
[SIESTA-L] Performing relaxation correctly
Dear SIESTA users, I wonder how to perform the geometry relaxation in order to get the structure which really exists. If I turn VariableCell = true, I will have both atomic coordinates and unit cell parameters being relaxed at the same time, and finally get some optimized structure. I was told this is not a good way of relaxation, and I need to relax atomic coordinates first (VaribaleCell=false) and then relax a unit cell keeping coordinates fixed (by GeometryConstarints). but in this case I'm not able to get relaxed structure (pressure and stresses remain big). So I ask experienced users briefly how do you perform relaxation and whether you relax atomic coordinates and unit cell volume at the same time. -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] SCF convergence problem on large system
Also increasing DM.NumberPulay will be helpful and possibly other parameters beginnging with DM. should be checked. On 27/04/07, Oleksandr Voznyy [EMAIL PROTECTED] wrote: Mixingweight 0.5 Have you tried smaller MixingWeight? Usually I find that values should be smaller than 0.1 I might agree with Adam, that if you have some partially filled states in the gap you would have problems with SCF convergence, so that more k-points would be needed, or try to increase ElectronicTemperature (by the way MP mixing has never worked for me, neither for GaAs nor for gold). -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] net charge calculation
ok, there some papers which use Mulliken population with SIESTA. For example, this one: http://arxiv.org/pdf/cond-mat/0008340 The authors say that differences (of net charges and BOP-s) are less sensitive to the choice of basis sets, so they can be meaningful. Can anybody confirm this? On 19/04/07, Yurko Natanzon [EMAIL PROTECTED] wrote: Dear Adam Gali, Andrei Postnikov, thank you for explanation. Actually, I'm not interested in particular numbers, but want to observe changes in ionic charges of atoms, neighboring to dopant and the dependence of such changes on a dopant concentration (comparabale to undoped system). Is it possible to do it with Mulliken analysis? And how does the charge depend on the basis? For example, I use standard DZP basis automatically generated by SIESTA, but for SiO2 I get negative charge of SI, and for GeO2 I get positive one. What can I do, if I want to use Ge and Si as dopants and compare their influence on net charges of nieghboring atoms? On 19/04/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Dear Yurko Natanzon, take care! Mulliken-charges could be meaningless by using diffusing orbitals. Draw the net charge density around the atoms (you can do it by SIESTA and utility programs provided with) and you can see that O is negatively polarized while Si is positively polarized opposite what Mulliken-charges would indicate. I suggest to implement and use Bader-charges for analyses which DOES NOT depend on the basis set. Yours, Adam Gali Species: Si Atom Qatom Qorb 3s 3s 3py 3pz 3px 3py 3pz 3px 3Pdxy 3Pdyz 3Pdz2 3Pdxz 3Pdx2-y2 1 4.026 0.404 0.474 0.308 0.152 0.308 0.254 0.394 0.254 0.338 0.330 0.259 0.330 0.219 4 4.026 0.404 0.474 0.308 0.152 0.308 0.254 0.394 0.254 0.338 0.330 0.259 0.330 0.219 Species: O Atom Qatom Qorb 2s 2s 2py 2pz 2px 2py 2pz 2px 2Pdxy 2Pdyz 2Pdz2 2Pdxz 2Pdx2-y2 2 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 3 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 5 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 6 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 mulliken: Qtot = 32.000 then oxygen has positive ionic charge (6-5.987), and silicon has negative (4-4.026). Does it make any sense?? On 19/04/07, Vasilii Artyukhov [EMAIL PROTECTED] wrote: Just subtract the ionic charge from the Mulliken population, you will get -.514 for O and +1.028 for Ti. 2007/4/19, Yurko Natanzon [EMAIL PROTECTED] : Dear SIESTers, I wonder how to calculate net ionic charge with SIESTA. For example, I have TiO2 anatase supercell with 12 atoms. Pseudopotential for Ti has valence electrons in 3s2 3p6 3d2 4s2 (12 electrons), O has 2s2 2p4 (6 electrons). Then i set WriteMullikenPop 2 and obtain 10.972 for each Ti 6.514 fo O Total charge is 10.972*4+6.514*8 = 96 which equals the total number of valence electrons. Then how to obtain net electric charges of Ti and O atoms? If it is the difference between number of valence electrons and a charge obtained by SIESTA, than it is much lower, than is reported in other calculations. Net charge should be around +2 for Ti and -1 for O. -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] --- Dr. Gali ÁdámAdam Gali, PhD Budapesti Műszaki és Department of Atomic Physics, Gazdaságtudományi Egyetem, Budapest University of Technology and Atomfizika Tanszék Economics Budapest, Budafoki út 8., Budafoki út 8., H-, Budapest, Hungary telefon: 463-1580telephone: [36]-(1)-463-1580 fax: 463-4357fax: [36]-(1)-463-4357 e-mail: [EMAIL PROTECTED] http://www.fat.bme.hu/homepages/galia/index.en.html
[SIESTA-L] Fwd: [SIESTA-L] net charge calculation
Dear Adam Gali, Andrei Postnikov, thank you for explanation. Actually, I'm not interested in particular numbers, but want to observe changes in ionic charges of atoms, neighboring to dopant and the dependence of such changes on a dopant concentration (comparabale to undoped system). Is it possible to do it with Mulliken analysis? And how does the charge depend on the basis? For example, I use standard DZP basis automatically generated by SIESTA, but for SiO2 I get negative charge of SI, and for GeO2 I get positive one. What can I do, if I want to use Ge and Si as dopants and compare their influence on net charges of nieghboring atoms? On 19/04/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Dear Yurko Natanzon, take care! Mulliken-charges could be meaningless by using diffusing orbitals. Draw the net charge density around the atoms (you can do it by SIESTA and utility programs provided with) and you can see that O is negatively polarized while Si is positively polarized opposite what Mulliken-charges would indicate. I suggest to implement and use Bader-charges for analyses which DOES NOT depend on the basis set. Yours, Adam Gali Species: Si Atom Qatom Qorb 3s 3s 3py 3pz 3px 3py 3pz 3px 3Pdxy 3Pdyz 3Pdz2 3Pdxz 3Pdx2-y2 1 4.026 0.404 0.474 0.308 0.152 0.308 0.254 0.394 0.254 0.338 0.330 0.259 0.330 0.219 4 4.026 0.404 0.474 0.308 0.152 0.308 0.254 0.394 0.254 0.338 0.330 0.259 0.330 0.219 Species: O Atom Qatom Qorb 2s 2s 2py 2pz 2px 2py 2pz 2px 2Pdxy 2Pdyz 2Pdz2 2Pdxz 2Pdx2-y2 2 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 3 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 5 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 6 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 mulliken: Qtot = 32.000 then oxygen has positive ionic charge (6-5.987), and silicon has negative (4-4.026). Does it make any sense?? On 19/04/07, Vasilii Artyukhov [EMAIL PROTECTED] wrote: Just subtract the ionic charge from the Mulliken population, you will get -.514 for O and +1.028 for Ti. 2007/4/19, Yurko Natanzon [EMAIL PROTECTED] : Dear SIESTers, I wonder how to calculate net ionic charge with SIESTA. For example, I have TiO2 anatase supercell with 12 atoms. Pseudopotential for Ti has valence electrons in 3s2 3p6 3d2 4s2 (12 electrons), O has 2s2 2p4 (6 electrons). Then i set WriteMullikenPop 2 and obtain 10.972 for each Ti 6.514 fo O Total charge is 10.972*4+6.514*8 = 96 which equals the total number of valence electrons. Then how to obtain net electric charges of Ti and O atoms? If it is the difference between number of valence electrons and a charge obtained by SIESTA, than it is much lower, than is reported in other calculations. Net charge should be around +2 for Ti and -1 for O. -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] --- Dr. Gali ÁdámAdam Gali, PhD Budapesti Műszaki és Department of Atomic Physics, Gazdaságtudományi Egyetem, Budapest University of Technology and Atomfizika Tanszék Economics Budapest, Budafoki út 8., Budafoki út 8., H-, Budapest, Hungary telefon: 463-1580telephone: [36]-(1)-463-1580 fax: 463-4357fax: [36]-(1)-463-4357 e-mail: [EMAIL PROTECTED] http://www.fat.bme.hu/homepages/galia/index.en.html --- -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] net charge calculation
Well, this works for TiO2, but when I tried to do it with SiO2, I've got: mulliken: Atomic and Orbital Populations: Species: Si Atom Qatom Qorb 3s 3s 3py 3pz 3px 3py 3pz 3px 3Pdxy 3Pdyz 3Pdz2 3Pdxz 3Pdx2-y2 1 4.026 0.404 0.474 0.308 0.152 0.308 0.254 0.394 0.254 0.338 0.330 0.259 0.330 0.219 4 4.026 0.404 0.474 0.308 0.152 0.308 0.254 0.394 0.254 0.338 0.330 0.259 0.330 0.219 Species: O Atom Qatom Qorb 2s 2s 2py 2pz 2px 2py 2pz 2px 2Pdxy 2Pdyz 2Pdz2 2Pdxz 2Pdx2-y2 2 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 3 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 5 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 6 5.987 1.136 0.383 1.391 1.164 1.391 0.139 0.226 0.139 0.003 0.005 0.003 0.005 0.003 mulliken: Qtot = 32.000 then oxygen has positive ionic charge (6-5.987), and silicon has negative (4-4.026). Does it make any sense?? On 19/04/07, Vasilii Artyukhov [EMAIL PROTECTED] wrote: Just subtract the ionic charge from the Mulliken population, you will get -.514 for O and +1.028 for Ti. 2007/4/19, Yurko Natanzon [EMAIL PROTECTED] : Dear SIESTers, I wonder how to calculate net ionic charge with SIESTA. For example, I have TiO2 anatase supercell with 12 atoms. Pseudopotential for Ti has valence electrons in 3s2 3p6 3d2 4s2 (12 electrons), O has 2s2 2p4 (6 electrons). Then i set WriteMullikenPop 2 and obtain 10.972 for each Ti 6.514 fo O Total charge is 10.972*4+6.514*8 = 96 which equals the total number of valence electrons. Then how to obtain net electric charges of Ti and O atoms? If it is the difference between number of valence electrons and a charge obtained by SIESTA, than it is much lower, than is reported in other calculations. Net charge should be around +2 for Ti and -1 for O. -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
[SIESTA-L] net charge calculation
Dear SIESTers, I wonder how to calculate net ionic charge with SIESTA. For example, I have TiO2 anatase supercell with 12 atoms. Pseudopotential for Ti has valence electrons in 3s2 3p6 3d2 4s2 (12 electrons), O has 2s2 2p4 (6 electrons). Then i set WriteMullikenPop 2 and obtain 10.972 for each Ti 6.514 fo O Total charge is 10.972*4+6.514*8 = 96 which equals the total number of valence electrons. Then how to obtain net electric charges of Ti and O atoms? If it is the difference between number of valence electrons and a charge obtained by SIESTA, than it is much lower, than is reported in other calculations. Net charge should be around +2 for Ti and -1 for O. -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] How to fix some of the atoms while doing relaxation
Dear Clutch, take a look at GeometryConstraints block in SIESTA manual. Also this topic was discussed recently on the list, you may search (Buscar en los archivos). You can fix selected atoms by fixing their positions, but it seems you have to write a routine to fix atoms in one direction. Examples of routines are in the manual and also on the list (by Pablo Aguado). On 11/04/07, Clutch Q. J. Fan [EMAIL PROTECTED] wrote: Dear SIESTA users: The atoms can fully relax if you do a relaxation. But if I want to fix some atoms, while the others can relax. Or if I want to make some atoms can only relax in z direction but are fixed in x and y direction. Can SIESTA do this? Thanks in advance. Yours Clutch 远离垃圾邮件？免费帮你过滤98％的垃圾邮件！www.126.com -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] xmgrace
Dear mian, An addition, you can use for example gnuplot instead of xmgrace or any other program. On 03/04/07, mian shabbir [EMAIL PROTECTED] wrote: Dear Sir I am new siesta user using a tutorial about silicon bulk.there is a problem that is when I go to plot bands.dat xmgrace bands.dat and select the correct range of energy. Now the problem is what is xmgrace.I did not find it in my out files and not anywhere in siesta software.Please help me a send some material about solution of these problems in future. best regards -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Restrict geometry optimization
thank you very much, your solution seems to be better. Is it correct that I can write several subroutines constr1 constr2 ... using the same template, put them into constr.f and use different routines for different calculations ? On 30/03/07, Pablo Aguado [EMAIL PROTECTED] wrote: Sorry, now it's attached. - should I only compile constr.f file or the whole siesta package must be recompiled? You have to recompile the whole package to get a binary file with the constr.f subroutine implemented. - if I want to keep unit cell angles fixed to 90, 90,90 degrees during VariableCell optimization, is it correct to apply the following constraints: cell(1,2) = 0 cell(1,3) = 0 cell(2,1) = 0 cell(2,3) = 0 cell(3,1) = 0 cell(3,2) = 0 ? I don't use that options so I can't tell you if that would work. In my constr.f I make the stress 0 in the diagonal directions, so the angles don't change. Regards Pablo -- --- Pablo Aguado Puente [EMAIL PROTECTED] -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] how to calculate the values of strain tensor from forces or stress tensor?
Vasilii, thank you for advice, I'll check it. But this works only if I don't put any geometry constraints. If I want ie fix the angles, I never get even low values of stress components - only change of angles will allow that. So in this case I need to take zero stress into account. In some cases, a simple difference between deformed and undeformed stress components can improve results, but I need more accurate formula and for this I have to know the strain tensor which corresponds to stress tensor calculated by SIESTA. On 27/03/07, Vasilii Artyukhov [EMAIL PROTECTED] wrote: If your system is not too large, I'd advise that you determine the relaxed lattice constants from a series of fixed-cell calculations, especially if the system is more or less symmetrical. Although your stresses seem quite low to me, I think that the only way to improve them might be, indeed, to lower the stress tolerance. Note that since you are using a finite integration grid, no one can guarantee that you will ever get zero stresses. So, check for the integration grid cutoff as well, you might have to increase it at some point. 2007/3/27, Yurko Natanzon [EMAIL PROTECTED]: Dear siesters, I'm thinking on increasing the accuracy of calculating elastic constants (i'm interested in shear ones but it doesn't matter). First I relax a lattice to get a stress tensor zero, and then make deformations to get a new stress tensor and calculate elastic constants. But in fact the stress tensor of relaxed lattice is not zero, it has a form like this one: -0.20 -0.56 0.000233 -0.56 0.53-0.33 0.000233-0.33 0.001350 the values of this tensor in fact influence the results of elastic constant calculations. In fact, if I get +1% deformation in one direction and -1% - I may get totally different values of stress tensor. Is there a way to take the influence of zero stress tensor into account? If I'll be able to know, which strain corresponds to this stress tensor, I can find the lattice vectors of ideally relaxed lattice, and this will solve the problem. I would be grateful for any advices regarding this. Of course, I may try to set StressTolerance and Force Tolerance to some low values, but this will take much more CG steps to fully relax the lattice and much more time. Also in some cases I can't fully relax the lattice because of constraints, but need to relax only several components of stress tensor. -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] gnubands
dear saswata, gnubands comes with SIESTA, compile file gnubands.f in Utils directory. xmgrace is not a part of SIESTA, but a free program called grace, available from the web. it comes with many linux distros, I have it as a part of my Fedora. On 27/03/07, Saswata Bhattacharya [EMAIL PROTECTED] wrote: dear friends, i want to know whether gnubands and xmgrace are two software packages that comes with SIESTA package or not?I have installed SIESTA and it is running nicely but there i dont get access of the software gnubands and xmgrace.mostly i have read that to convert .bands file to .dat file we need gnubands.right?and to plot .band we need xmgrace software...but if in my SIESTA package these two are absent then how can i get access of these two?i mean how to plot the file .band to get the bands structure? next my question is how to plot the file .PDOS to visualize partial DOS? please help.i am waiting for your reply... with regards, Saswata Here's a new way to find what you're looking for - Yahoo! Answers -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] SPAM : Re: [SIESTA-L] Diag.ParallelOverK
Well, I have a proposal to developers to implement a kind of spell check. It would be really useful if SIESTA run stops when unknown parameter is found in the input file. On 22/03/07, Emilio Artacho [EMAIL PROTECTED] wrote: Dear Yurko and Bipul That was an excellent spotting, Yurko! I thought I used this case as a reminder of the usefulness of checking the out.fdf file when looking for problems in a calculation. That file contains what has been actually used in the last calculation (In this case it would say Diag.ParallelOverK .false. (default) because it didn't find that particular label). Emilio Yurko Natanzon wrote: dear bipul, it seems you have a mistake in your input file: Diag.PatallelOverK.true. you should correct into Diag.ParallelOverK .true. On 22/03/07, bipul rakshit [EMAIL PROTECTED] wrote: hello siesta user, i am running siesta in parallel AIX machine. I use the Diag.ParallelOverK .true. and then run the siesta... i use two processor to run siesta... but i saw that the siesta run will take same time, when i dont use the above option... can any body suggest me how to reduce the computational time.. Here's a new way to find what you're looking for - Yahoo! Answers Sender: LSF System [EMAIL PROTECTED] Subject: Job 161390: /afs/enea.it/software/bin/poe.lsf shell.sh -procs 2 -sharedmemory yes Done Job /afs/enea.it/software/bin/poe.lsf shell.sh -procs 2 -sharedmemory yes was submitted from host sp5-1.frascati.enea.it by user rakshit. Job was executed on host(s) 2*sp4-3.frascati.enea.it, in queue large_72h, as user rakshit. /afs/enea.it/fra/user/rakshit was used as the home directory. /afs/enea.it/fra/user/rakshit/aix/siesta-2.0/ptn/ptn_LDA_RS was used as the working directory. Started at Thu Mar 22 12:42:38 2007 Results reported at Thu Mar 22 13:26:10 2007 Your job looked like: # LSBATCH: User input /afs/enea.it/software/bin/poe.lsf shell.sh -procs 2 -sharedmemory yes Successfully completed. Resource usage summary: CPU time : 0.36 sec. Max Memory : 4 MB Max Swap : 6 MB Max Processes : 4 Max Threads: 4 The output (if any) follows: Siesta Version: siesta-2.0-release Architecture : powerpc-ibm-aix5.2.0.0--Xlf Compiler flags: mpxlf95 -O3 -qarch=auto -qtune=auto -qcache=auto -q64 -qfixed -qnolm -qzerosize -qstrict -qmaxmem=-1 PARALLEL version * Running on2 nodes in parallel Start of run: 22-MAR-2007 12:42:40 *** * WELCOME TO SIESTA * *** reinit: Reading from standard input ** Dump of input data file # $Id: ptn.fdf,v 1.1 1999/04/20 14:43:44 emilio Exp $ # - # FDF fo # # E. Artacho, April 1999 # - SystemName ptnRS SystemLabel ptnRS NumberOfAtoms 2 NumberOfSpecies 2 %block ChemicalSpeciesLabel 1 78Pt 2 7N %endblock ChemicalSpeciesLabel PAO.BasisType split #PAO.BasisSize DZP PAO.EnergyShift 0.1eV PAO.SplitNorm 0.2000 %block PAO.Basis # Define Basis set Pt 2# Species label, number of l-shells n=6 0 2 P 1 # n, l, Nzeta, Polarization, NzetaPol 6.982 5.645 1.000 1.000 n=5 2 2 # n, l, Nzeta 5.044 2.803 1.000 1.000 N 3 -0.00139 n=2 0 2 E 65.50216 4.29661 5.64483 3.02914 1.00 1.00 n=2 1 2 E 30.54417 5.81284 7.25855 2.85547 1.00 1.00 n=3 2 1 E 59.15335 0.14049 3.65788 1.00 %endblock PAO.Basis LatticeConstant 4.8041 Ang #%block LatticeParameters # 3.92 3.92 3.92 60.0 60.0 60.0 #%endblock LatticeParameters %block LatticeVectors 0.5 0.50.0 0.5 0.00.5 0.0 0.50.5 %endblock LatticeVectors MeshCutoff250.00 Ry # SCF options MaxSCFIterations 200 # 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 WriteCoorXmol WriteMullikenPop 1 WriteForces .true. ElectronicTemperature30 meV xc.functionalLDA xc.authors CA # WriteCoorStep.true
Re: [SIESTA-L] Diag.ParallelOverK
dear bipul, it seems you have a mistake in your input file: Diag.PatallelOverK.true. you should correct into Diag.ParallelOverK .true. On 22/03/07, bipul rakshit [EMAIL PROTECTED] wrote: hello siesta user, i am running siesta in parallel AIX machine. I use the Diag.ParallelOverK .true. and then run the siesta... i use two processor to run siesta... but i saw that the siesta run will take same time, when i dont use the above option... can any body suggest me how to reduce the computational time.. Here's a new way to find what you're looking for - Yahoo! Answers Sender: LSF System [EMAIL PROTECTED] Subject: Job 161390: /afs/enea.it/software/bin/poe.lsf shell.sh -procs 2 -sharedmemory yes Done Job /afs/enea.it/software/bin/poe.lsf shell.sh -procs 2 -sharedmemory yes was submitted from host sp5-1.frascati.enea.it by user rakshit. Job was executed on host(s) 2*sp4-3.frascati.enea.it, in queue large_72h, as user rakshit. /afs/enea.it/fra/user/rakshit was used as the home directory. /afs/enea.it/fra/user/rakshit/aix/siesta-2.0/ptn/ptn_LDA_RS was used as the working directory. Started at Thu Mar 22 12:42:38 2007 Results reported at Thu Mar 22 13:26:10 2007 Your job looked like: # LSBATCH: User input /afs/enea.it/software/bin/poe.lsf shell.sh -procs 2 -sharedmemory yes Successfully completed. Resource usage summary: CPU time : 0.36 sec. Max Memory : 4 MB Max Swap : 6 MB Max Processes : 4 Max Threads: 4 The output (if any) follows: Siesta Version: siesta-2.0-release Architecture : powerpc-ibm-aix5.2.0.0--Xlf Compiler flags: mpxlf95 -O3 -qarch=auto -qtune=auto -qcache=auto -q64 -qfixed -qnolm -qzerosize -qstrict -qmaxmem=-1 PARALLEL version * Running on2 nodes in parallel Start of run: 22-MAR-2007 12:42:40 *** * WELCOME TO SIESTA * *** reinit: Reading from standard input ** Dump of input data file # $Id: ptn.fdf,v 1.1 1999/04/20 14:43:44 emilio Exp $ # - # FDF fo # # E. Artacho, April 1999 # - SystemName ptnRS SystemLabel ptnRS NumberOfAtoms 2 NumberOfSpecies 2 %block ChemicalSpeciesLabel 1 78Pt 2 7N %endblock ChemicalSpeciesLabel PAO.BasisType split #PAO.BasisSize DZP PAO.EnergyShift 0.1eV PAO.SplitNorm 0.2000 %block PAO.Basis # Define Basis set Pt 2# Species label, number of l-shells n=6 0 2 P 1 # n, l, Nzeta, Polarization, NzetaPol 6.982 5.645 1.000 1.000 n=5 2 2 # n, l, Nzeta 5.044 2.803 1.000 1.000 N 3 -0.00139 n=2 0 2 E 65.50216 4.29661 5.64483 3.02914 1.00 1.00 n=2 1 2 E 30.54417 5.81284 7.25855 2.85547 1.00 1.00 n=3 2 1 E 59.15335 0.14049 3.65788 1.00 %endblock PAO.Basis LatticeConstant 4.8041 Ang #%block LatticeParameters # 3.92 3.92 3.92 60.0 60.0 60.0 #%endblock LatticeParameters %block LatticeVectors 0.5 0.50.0 0.5 0.00.5 0.0 0.50.5 %endblock LatticeVectors MeshCutoff250.00 Ry # SCF options MaxSCFIterations 200 # 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 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 180 # 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. Diag.PatallelOverK.true. %block kgrid_Monkhorst_Pack 12 000.0 012 00.0 0012 0.0 %endblock kgrid_Monkhorst_Pack
Re: [SIESTA-L] Cu slab
I would recommend to post also first 2-3 lines of your pseudo file, where the pseudopotential info is stored. For this reason I would use ascii .psf file instead of .vps, because the sooner is more readable. Also the input file used for pseudopotential genaration will be helpful. I'm not sure, but it seems you haven't included some valence orbitals. On 09/03/07, Ian Shuttleworth [EMAIL PROTECTED] wrote: Siesterers, I'm attempting to model a Cu slab, starting from a single layer of Cu atoms, then wanting to generate up to 3 layers, and use a repeating slab ordinance. Using both the Cu PP extracted from the siesta-2.0.1 distribution and the octopus PP, I keep finding the same message when I run the simulation atom: Called for Cu (Z = 29) read_vps: ERROR: You must generate a pseudopotential read_vps: ERROR: for each L up to3 How do I handle delivering multiple PP's? I've put the FDF file below for reference. With thanks Ian *** SystemName cu001 SystemLabel cu001 NumberOfAtoms 15 NumberOfSpecies 1 MeshCutoff 50 Ry %block ChemicalSpeciesLabel 1 29 CU # Species index, atomic number, species label %endblock ChemicalSpeciesLabel AtomicCoordinatesFormat Ang %block AtomicCoordinatesAndAtomicSpecies -5.100 -2.550 0.000 1 -2.550 -2.550 0.000 1 0.000 -2.550 0.000 1 2.550 -2.550 0.000 1 5.100 -2.550 0.000 1 -5.100 0.000 0.000 1 -2.550 0.000 0.000 1 0.000 0.000 0.000 1 2.550 0.000 0.000 1 5.100 0.000 0.000 1 -5.100 2.550 0.000 1 -2.550 2.550 0.000 1 0.000 2.550 0.000 1 2.550 2.550 0.000 1 5.100 2.550 0.000 1 %endblock AtomicCoordinatesAndAtomicSpecies HarrisFunctional T Solution.Method diagon MeshCutoff 100 Ry WriteCoorStep .false. WriteForces.true. WriteMDHistory .true. MD.UseSaveXV T MD.TypeOfRun Verlet MD.InitialTemperature 300 K MD.Initial.Time.Step 1 MD.Final.Time.Step2 MD.Length.Time.Step 1 fs save-rho T save-delta-rho T save-total-potential T save-hs T -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] how to increase accuracy of bulk modulus calculations?
Olexandr, Vasilii, thank you for suggestions. I'm trying to calculate bulk modulus of tetragonal, monoclinic and cubic zirconium dioxide. With deformation +-2% I get rather good results for tetragonal and monoclinic phase, but still not good results for cubic phase. I'll try your suggestion of fitting 5 points with deformation +- 1% . On 08/03/07, Vasilii Artyukhov [EMAIL PROTECTED] wrote: In my experience, very good bulk moduli are produced by a simple quartic fit to five points no far than 1% off the equilibrium, you don't actually need lots of points or the Murnaghan fit (as long as you keep your points close enough to the equilibrium value). Just run five calculations with fixed lattice constants. Though you should check for the discontinuities caused by a finite integration grid (MeshCutoff). It is also very important which material you are studying, for example you shouldn't expect good results with molecular crystals like fullerite. Could you please specify the material? 2007/3/1, Oleksandr Voznyy [EMAIL PROTECTED]: Do you have a cubic cell? Don't do VariableCell then, it destroys symmetry. (check the forces on atoms to be 0) If you know the exact symmetry of the cell (relative positions of atoms in the cell) then adjust only lattice constant. Then the effect of pressure in all direction will change the lattice equivalently as well. With the same relative coordinates just change the lattice constant in the range +-3% with the step 0.25-0.5% and check the total energies. -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
[SIESTA-L] how to increase accuracy of bulk modulus calculations?
Dear siesters, I'm trying to calculate bulk modulus and cannot get reasonable results. I start from some unrelaxed cubic structure and run VariableCell optimization. I obtain some relaxed structure with reasonable lattice constant. Then I repeat the same calculations but set nonzero value of MD.TargetPressure. By varying these parameter I obtain a set of points TotalEnergy vs lattice constant. I use two programs to fit with Murnaghan eq. and get bulk modulus, both programs give similar results, but far from experimental one. Also results are changed a lot by variyng a number of such points. So the question is: what is the optimal number of points needed to obtain as accurate results as possible? What is the reasonable range of target pressures for this point? Also any other advices from those who have an experience in calculating bulk modulus is appreciated. Thanks in advance, with best regards, -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
[SIESTA-L] Convergence vs MeshCutoff problem
dear siesta users, I've made a series of tests with one CG move in order to determine the appropriate cutoff for further calculations. Unfortunately, I didn't manage to achieve the convergence, the energy still changes with the increasing of cutoff: Cutoff, Ry Energy, eV 70 -8636.77259 80 -8636.7726 90 -8636.7726 100 -8637.3829 110 -8637.1839 120 -8637.1839 130 -8637.1839 140 -8637.1765 150 -8637.1765 200 -8637.1352 250 -8637.1321 If I set some GridSampling, for example this one: %block GridCellSampling 0.5 0.0 0.0 0.0 0.5 0.0 0.0 0.0 0.5 0.0 0.5 0.5 0.5 0.0 0.5 0.5 0.5 0.0 0.5 0.5 0.5 %endblock GridCellSampling The difference in energies become smaller, but still no convergence: Cutoff, Ry Energy, eV 70 -8637.1422 80 -8637.1422 90 -8637.1422 100 -8637.1398 110 -8637.1387 120 -8637.1387 130 -8637.1387 140 -8637.1375 150 -8637.1375 200 -8637.1380 250 -8637.1369 I'd be grateful if anyone can give me any advice on this. A sample of input file is attached -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] pos.fdf Description: application/vnd.fdf start.fdf Description: application/vnd.fdf
[SIESTA-L] Fwd: [SIESTA-L] In running parallel siesta the energy is too large...
Dear bipul rakshit, I see you are using Portland compiler with -fast flag. It is known for causing problems like crashes and bad results for siesta 2.0 at least. I suggest to play with optimization flags, for example, change to -O2, -O1 or so. On 21/02/07, bipul rakshit [EMAIL PROTECTED] wrote: hello siesta user, i am running siesta in parallel. As a test i run the same problem in parallel which i already run in serial. But now the energy of the system in parallel become very large as compared to the same system when i run in serial.. can anybody suggest me what is the problem i am sending the two output file as tmse.serial and tmse.parallel for serial and parallel results respec... thanks Here's a new way to find what you're looking for - Yahoo! Answers --0-2002543467-1172055332=:51085-- Siesta Version: siesta-2.0-release Architecture : i686-pc-linux-gnu--Portland Compiler flags: mpif90 -g -fast PARALLEL version * Running in serial mode with MPI Start of run: 21-FEB-2007 11:44:07 *** * WELCOME TO SIESTA * *** reinit: Reading from standard input ** Dump of input data file # $Id: ptn.fdf,v 1.1 1999/04/20 14:43:44 emilio Exp $ # - # FDF fo # # E. Artacho, April 1999 # - SystemName tmse SystemLabel tmse NumberOfAtoms 2 NumberOfSpecies 2 %block ChemicalSpeciesLabel 1 69Tm 2 34Se %endblock ChemicalSpeciesLabel PAO.BasisType split #PAO.BasisSize DZP PAO.EnergyShift 0.1eV PAO.SplitNorm 0.2000 %block PAO.Basis # Define Basis set Tm 2# Species label, number of l-shells n=6 0 2 P 1 # n, l, Nzeta, Polarization, NzetaPol 6.982 5.645 1.000 1.000 # n=5 2 2 # n, l, Nzeta # 5.044 2.803 # 1.000 1.000 n=4 3 2 P 6.982 5.645 1.000 1.000 Se 2 n=4 0 2 5.64483 3.02914 1.00 1.00 n=4 1 2 7.25855 2.85547 1.00 1.00 %endblock PAO.Basis LatticeConstant 5.6900 Ang #%block LatticeParameters # 3.92 3.92 3.92 60.0 60.0 60.0 #%endblock LatticeParameters %block LatticeVectors 0.5 0.50.0 0.5 0.00.5 0.0 0.50.5 %endblock LatticeVectors MeshCutoff250.00 Ry # SCF options MaxSCFIterations 200 # 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 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 180 # 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 12 000.0 012 00.0 0012 0.0 %endblock kgrid_Monkhorst_Pack Diag.DivideAndConquer .false. ** End of input data file * reinit: --- reinit: System Name: tmse reinit: --- reinit: System Label: tmse reinit: --- initatom: Reading input for the pseudopotentials and atomic orbitals -- Species number: 1 Label: Tm Atomic number: 69 Species number: 2 Label: Se Atomic number: 34 Ground state valence configuration: 6s02 4f13 Reading pseudopotential information in formatted form from Tm.psf Ground state valence configuration: 4s02 4p04 Reading pseudopotential information in formatted form from Se.psf For Tm, standard SIESTA heuristics set lmxkb to 5 (one more than the basis l, including polarization orbitals). Use PS.lmax or PS.KBprojectors blocks to
Re: [SIESTA-L] input file for parallel siesta
The's no difference, but there are some additional options for parallel computations. You may find this in the manual. Also read previous e-mails - some problems were reported for small systems running on computers with 4 processors. As for your previous e-mail, I also haven't managed to compile siesta in parallel on AMD64 Opteron machine with pgf90 - linking fails. But you may compile it on Itel machine with Intel compilers, and use it on AMD machine - it should work. On 09/02/07, bipul rakshit [EMAIL PROTECTED] wrote: hello siesta users, can you tell me is there is any difference in the input of the *.fdf file for parallel seista. if yes then can any body send a copy of fdf file. plz Here's a new way to find what you're looking for - Yahoo! Answers -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] MPI compilation problem
Dear Jess, I'm very grateful to you. I just deleted -static option from LD_FLAGS in arch.make and everything has compiled! Hope other users won't repeat my mistake. On 08/02/07, Jess Kondor [EMAIL PROTECTED] wrote: Please, get rid of '-static' option. It is very dangerous to use it. It is better to use '-i-static' option instead. On 2/8/07, Yurko Natanzon [EMAIL PROTECTED] wrote: Dear Sebastien, Acttually the same problem I have as a result: mpif90 -o kind_explorer -Vaxlib -static kind_explorer.o /opt/intel/fc/lib/libifcore.a(for_open_proc.o): In function `for__compute_filename.': ./src/libfor/for_open_proc.c:(.text+0xc14): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./src/libfor/for_open_proc.c:(.text+0xd05): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/libc.a(iofclose.o):(.eh_frame+0x121): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(iofputs.o): In function `fputs': (.text+0x102): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(iofputs.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(wfileops.o): In function `_IO_wfile_underflow': (.text+0x1224): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(wfileops.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(freopen64.o): In function `freopen64': (.text+0x1f3): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(freopen64.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(fileops.o): In function `_IO_file_underflow': (.text+0x14ab): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(fileops.o): In function `_IO_file_fopen': (.text+0x1ccb): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(fileops.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(syslog.o): In function `openlog': (.text+0x332): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o): In function `__vsyslog_chk': (.text+0x87f): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o): In function `__vsyslog_chk': (.text+0x891): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o): In function `closelog': (.text+0x9b8): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o):(.eh_frame+0x166): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(backtrace.o): In function `backtrace': (.text+0x54): undefined reference to `_Unwind_Backtrace' /usr/lib/libc.a(backtrace.o): In function `backtrace_helper': (.text+0x10a): undefined reference to `_Unwind_GetIP' /usr/lib/libc.a(backtrace.o): In function `backtrace_helper': (.text+0x12f): undefined reference to `_Unwind_GetGR' /usr/lib/libc.a(backtrace.o): In function `backtrace_helper': (.text+0x13a): undefined reference to `_Unwind_GetCFA' /usr/lib/libc.a(iofwrite.o): In function `fwrite': (.text+0x125): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(iofwrite.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' On 08/02/07, Sebastien LeRoux [EMAIL PROTECTED] wrote: Yurko Natanzon a écrit : Dear Sebastien, thank you for your help. I was confused with mpif90 output and thought that it didn't work. Now I've recompiled successfully blacs and scalapack with mpif90/mpicc, but now the siesta compilation fails at the beginning: ... make[2]: Entering directory `/opt/siesta/Src/MPI' mpif90 -o kind_explorer -Vaxlib -static kind_explorer.o /opt/intel/fc/lib/libifcore.a(for_open_proc.o): In function `for__compute_filename.': Your arch.make is ok, the problem comes from the compilation of MPI interface tools for Siesta do the following commands and try to compile again: ]% cd siesta/Src/MPI ]% make clean you can test the following line: ]% mpif90 -o kind_explorer -Vaxlib -static kind_explorer.f90 'you may have a problem here that's what appears in your output' Anyway create the MPI modules: ]% make then compile siesta: ]% cd .. ]% make Best. -- Sébastien Le Roux Doctorant LPMC-Institut C. Gerhardt UMR 5253 CC003 Université de Montpellier II Place E. Bataillon 34095 MONTPELLIER cedex 05 E mail: [EMAIL PROTECTED] Tel: +33(0)4.67.14.41.21 Fax: +33(0)4.67.14.41.90 -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL
Re: [SIESTA-L] MPI compilation problem
Dear Sebastien, Acttually the same problem I have as a result: mpif90 -o kind_explorer -Vaxlib -static kind_explorer.o /opt/intel/fc/lib/libifcore.a(for_open_proc.o): In function `for__compute_filename.': ./src/libfor/for_open_proc.c:(.text+0xc14): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./src/libfor/for_open_proc.c:(.text+0xd05): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/libc.a(iofclose.o):(.eh_frame+0x121): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(iofputs.o): In function `fputs': (.text+0x102): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(iofputs.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(wfileops.o): In function `_IO_wfile_underflow': (.text+0x1224): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(wfileops.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(freopen64.o): In function `freopen64': (.text+0x1f3): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(freopen64.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(fileops.o): In function `_IO_file_underflow': (.text+0x14ab): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(fileops.o): In function `_IO_file_fopen': (.text+0x1ccb): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(fileops.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(syslog.o): In function `openlog': (.text+0x332): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o): In function `__vsyslog_chk': (.text+0x87f): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o): In function `__vsyslog_chk': (.text+0x891): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o): In function `closelog': (.text+0x9b8): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o):(.eh_frame+0x166): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(backtrace.o): In function `backtrace': (.text+0x54): undefined reference to `_Unwind_Backtrace' /usr/lib/libc.a(backtrace.o): In function `backtrace_helper': (.text+0x10a): undefined reference to `_Unwind_GetIP' /usr/lib/libc.a(backtrace.o): In function `backtrace_helper': (.text+0x12f): undefined reference to `_Unwind_GetGR' /usr/lib/libc.a(backtrace.o): In function `backtrace_helper': (.text+0x13a): undefined reference to `_Unwind_GetCFA' /usr/lib/libc.a(iofwrite.o): In function `fwrite': (.text+0x125): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(iofwrite.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' On 08/02/07, Sebastien LeRoux [EMAIL PROTECTED] wrote: Yurko Natanzon a écrit : Dear Sebastien, thank you for your help. I was confused with mpif90 output and thought that it didn't work. Now I've recompiled successfully blacs and scalapack with mpif90/mpicc, but now the siesta compilation fails at the beginning: ... make[2]: Entering directory `/opt/siesta/Src/MPI' mpif90 -o kind_explorer -Vaxlib -static kind_explorer.o /opt/intel/fc/lib/libifcore.a(for_open_proc.o): In function `for__compute_filename.': Your arch.make is ok, the problem comes from the compilation of MPI interface tools for Siesta do the following commands and try to compile again: ]% cd siesta/Src/MPI ]% make clean you can test the following line: ]% mpif90 -o kind_explorer -Vaxlib -static kind_explorer.f90 'you may have a problem here that's what appears in your output' Anyway create the MPI modules: ]% make then compile siesta: ]% cd .. ]% make Best. -- Sébastien Le Roux Doctorant LPMC-Institut C. Gerhardt UMR 5253 CC003 Université de Montpellier II Place E. Bataillon 34095 MONTPELLIER cedex 05 E mail: [EMAIL PROTECTED] Tel: +33(0)4.67.14.41.21 Fax: +33(0)4.67.14.41.90 -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] MPI compilation problem
Dear Sebastien, thank you for your help. I was confused with mpif90 output and thought that it didn't work. Now I've recompiled successfully blacs and scalapack with mpif90/mpicc, but now the siesta compilation fails at the beginning: ... make[2]: Entering directory `/opt/siesta/Src/MPI' mpif90 -o kind_explorer -Vaxlib -static kind_explorer.o /opt/intel/fc/lib/libifcore.a(for_open_proc.o): In function `for__compute_filename.': ./src/libfor/for_open_proc.c:(.text+0xc14): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./src/libfor/for_open_proc.c:(.text+0xd05): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/libc.a(iofclose.o):(.eh_frame+0x121): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(iofputs.o): In function `fputs': (.text+0x102): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(iofputs.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(wfileops.o): In function `_IO_wfile_underflow': (.text+0x1224): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(wfileops.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(freopen64.o): In function `freopen64': (.text+0x1f3): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(freopen64.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(fileops.o): In function `_IO_file_underflow': (.text+0x14ab): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(fileops.o): In function `_IO_file_fopen': (.text+0x1ccb): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(fileops.o):(.eh_frame+0xde): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(syslog.o): In function `openlog': (.text+0x332): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o): In function `__vsyslog_chk': (.text+0x87f): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o): In function `__vsyslog_chk': (.text+0x891): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o): In function `closelog': (.text+0x9b8): undefined reference to `_Unwind_Resume' /usr/lib/libc.a(syslog.o):(.eh_frame+0x166): undefined reference to `__gcc_personality_v0' /usr/lib/libc.a(backtrace.o): In function `backtrace': ... I attach arch.make once again. My yesterdays arch.make was the same, but I used ifort instead of mpif90. However, with ifort I get the same errors. On 08/02/07, Sebastien LeRoux [EMAIL PROTECTED] wrote: Yurko Natanzon a écrit : So I compiled everything with ifort and icc instead of mpif90/mpicc. Also I use 9.1 version of ifort/icc. Could this be the problem? I attach my new arch.make together with makefiles of mpich2 and all the libraries. Hi dear Yurko Natanzon, Your arch.make file was not attached to your last email. I've got an empty file actually, and after reading your old file (yesterday email) I see a few mistakes. Can you please send me back the new one. The compiler version is definitely not a problem, but I am not sure that the compilation using ifort/icc will be successful in order to obtain a parallel build, I think that mpif90/mpicc have to be used at least for the link process. Otherwise: /opt/intel/fc/9.1.036/lib/for_main.o: In function `main': ./src/libfor/for_main.c:(.text+0x3e): undefined reference to `MAIN__' is the message provide by mpif90 (and not by ifort .. this is an output of mpif90 !) when no file is given as input ... so you don't have any problems with the compiler. Best Sébastien Le Roux -- Sébastien Le Roux Doctorant LPMC-Institut C. Gerhardt UMR 5253 CC003 Université de Montpellier II Place E. Bataillon 34095 MONTPELLIER cedex 05 E mail: [EMAIL PROTECTED] Tel: +33(0)4.67.14.41.21 Fax: +33(0)4.67.14.41.90 -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] arch.make Description: Binary data
Re: [SIESTA-L] MPI compilation problem
Dear Marcel, thank you for suggestions, but I didn't help :( I followed the instructions of Sebastien's how-to and everything seemed to be ok, except the last stage of SIESTA linking : ... /siesta/libs/blacs_MPI-LINUX-0.a(BI_Pack.o): In function `BI_Pack': BI_Pack.c:(.text+0x31): undefined reference to `MPI_Pack' BI_Pack.c:(.text+0x59): undefined reference to `MPI_Pack_size' /opt/siesta/libs/blacs_MPI-LINUX-0.a(BI_GetMpiGeType.o): In function `BI_GetMpiGeType': BI_GetMpiGeType.c:(.text+0x20): undefined reference to `MPI_Type_vector' BI_GetMpiGeType.c:(.text+0x2a): undefined reference to `MPI_Type_commit' /opt/siesta/libs/blacs_MPI-LINUX-0.a(BI_GetMpiTrType.o): In function `BI_GetMpiTrType': BI_GetMpiTrType.c:(.text+0x252): undefined reference to `MPI_Type_indexed' BI_G ... and so on. I did exactly what Sebastien advised, but mpif90 and mpif77, mpicc doesn't work: [EMAIL PROTECTED] Src]# [EMAIL PROTECTED] bin]# ./mpif90 /opt/intel/fc/9.1.036/lib/for_main.o: In function `main': ./src/libfor/for_main.c:(.text+0x3e): undefined reference to `MAIN__' So I compiled everything with ifort and icc instead of mpif90/mpicc. Also I use 9.1 version of ifort/icc. Could this be the problem? I attach my new arch.make together with makefiles of mpich2 and all the libraries. On 07/02/07, Marcel Mohr [EMAIL PROTECTED] wrote: Dear Yurko have you also downloaded icc? You should compile scalapack Co with icc ifort. Look in the mailing list for a guide written by sebastian le roux. And by the way, compile mpich 2.0 by yourself could help too. On Wed, 7 Feb 2007, Yurko Natanzon wrote: LAPACK=-lmkl_lapack BLAS=-lmkl_ia32 These are the intel mkls, aren't they? Better try your own compiled. Regards Marcel -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] arch.make Description: Binary data Bmake.inc Description: Binary data make.inc_lapack Description: Binary data Makefile_mpich2-1.0.3 Description: Binary data SLmake.inc Description: Binary data
Re: [SIESTA-L] MPI compilation problem
Dear colleagues, Actually I have the same problem with parallel compilation of SIESTA on Intel Core Duo machine. I've downloaded and installed Intel Fortran Compiler (ifort), Intel MKL Libraries Cluster Edition, Intel MPI. I've also compiled scalapack and blas from scratch, but still have lots of undefined reference errors. Here comes my arch.make: FC=ifort # FFLAGS= -w -mp -tpp5 -O3 FFLAGS_DEBUG= -g LDFLAGS=-Vaxlib COMP_LIBS= RANLIB=echo # NETCDF_LIBS= NETCDF_INTERFACE= DEFS_CDF= # MPI_INTERFACE=libmpi_f90.a MPI_INCLUDE=/opt/intel/mpi/include/ MPI_LIBS=/opt/intel/mpi/lib/ DEFS_MPI=-DMPI # GUIDE=-lguide LAPACK=-lmkl_lapack BLAS=-lmkl_ia32 LIBS=-L/opt/siesta/libs -lscalapack -lblacsF77init -lblacs \ -lblacsCinit -lblacs -L/opt/intel/mkl/lib/32 $(LAPACK) $(BLAS) $(G2C) \ $(GUIDE) -lpthread 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) $ I would be grateful if anyone can help me. regards, Yurko On Fri, 31 Mar 2006 18:18:47 +0200, Marcos Verissimo Alves [EMAIL PROTECTED] wrote: Guilherme, The problem is that the compiler cannot find the mpi libs. If you have compiled mpi, blacs, scalapack, all from scratch, then your arch.make should contain lines such as MPI_INTERFACE= libmpi_f90.a MPI_INCLUDE= /opt/mpich-gm/include/ MPI_LIBS= /opt/mpich-gm/lib/ DEFS_MPI= -DMPI SCALAPACK= # GUIDE=-lguide LAPACK=-lmkl_lapack BLAS=-lmkl_ia32 LIBS=-L/storage/mverissi/libs -lscalapack -lblacsF77init -lblacs -lblacsCinit -lcblas -L/opt/intel/mkl721/lib/32 $(LAPACK) $(BLAS) $(G2C) $(GUIDE) -lpthread Of course, all these lines should contain the appropriate directories. This is part of an arch.make that I have used to compile it on a cluster here at the ICTP. So, I cannot guarantee that this will solve your problem at all. However, I am pretty sure that the order in which libraries are listed for the compiler is very important, so: - Place the appropriate directories (include and libs) for mpi in the MPI_INCLUDE and MPI_LIBS lines; - In the LIBS line, first list the scalapack, blacs and cblas as listed here, then the mkl or other mathematical libraries you might be using. I haven't tested if the mkl are really necessary when you already have scalapack and related stuff. But, I decided to stay on the safe side and include them. Doesn't hurt, after all. :) Hope this works. Good luck, Marcos Hey everybody, i with some problems when i try to compile SIESTA with MPI support ... it´s retourning me a lot of error messages, and i´ll paste some of them, maybe someone had the same problem and could help me with this. /root/siesta-2.0/Src/MPI/Interfaces.f90:3317: undefined reference to `mpi_isend_' libmpi_f90.a(Interfaces.o)(.text+0x2644): In function `mpi_ibsend_t': /root/siesta-2.0/Src/MPI/Interfaces.f90:3332: undefined reference to `mpi_ibsend_' libmpi_f90.a(Interfaces.o)(.text+0x268c): In function `mpi_issend_t': /root/siesta-2.0/Src/MPI/Interfaces.f90:3347: undefined reference to `mpi_issend_' libmpi_f90.a(Interfaces.o)(.text+0x26d4): In function `mpi_irsend_t': /root/siesta-2.0/Src/MPI/Interfaces.f90:3362: undefined reference to `mpi_irsend_' libmpi_f90.a(Interfaces.o)(.text+0x271c): In function `mpi_irecv_t': /root/siesta-2.0/Src/MPI/Interfaces.f90:3377: undefined reference to `mpi_irecv_' I´m compiling SIESTA in a dual opteron 4 Gb Ram, and running SuSE linux 10.0. I had a sucesfull compilation, when i compile it in serial mode. Thank anyway Att. Guilherme Fernandes de Souza Miguel DirPD - Divisao de Redes - UFU -- 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] A Question About Pseu
Dear 陈学龙, pg means pseudopotential generation without nonlinear core correction while pe tells atom to use core correction (exchange) As for lodger radius, maybe anyone else will help you On 26/01/07, 陈学龙 [EMAIL PROTECTED] wrote: Hi,everyone Anyone who have read the ATOM User Manual? I am puzzled by the logder R during the pseudopotential generation. Take O for example in the O.tm2.inp: # pg Oxygen tm2 2.0 n=O c=ca 0.0 0.0 0.0 0.0 0.0 0.0 14 20 2.00 0.00 21 4.00 0.00 32 0.00 0.00 43 0.00 0.00 1.15 1.15 1.15 1.15 # Where does the number 2.0 come from ? Is there any differences between different jobcodes (pg and pe )? Thanks in advance! -- Yurko Natanzon PhD Student Henryk Niewodnicza��ski Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Construction of GGA pseudopotential from LDA inputdata
Oh sorry, I should have looked at this page: http://staff.aist.go.jp/t-ozaki/vps_pao2006/vps_pao.html There plenty of pseudos available for most elements, so just useful to take core radii from pseudo.NandL block of vps file. It seems that the same radii are used both for LDA and GGA, they are then varied during the calculations. On 16/12/06, Yurko Natanzon [EMAIL PROTECTED] wrote: Dear Vasilii, thank you for the information. Yes, there are some input file templates available together with ADPACK sources, so I can take cutoff radii. Unfortunately, not all the elements I need are available. I put below the link for other users to make use of this: http://staff.aist.go.jp/t-ozaki/adpack/adpack.html On 16/12/06, Vasilii Artyukhov [EMAIL PROTECTED] wrote: I think that you could use the radii from Dr. Ozaki's database of pseudopotentials for OpenMX. Since the method is essentially the same, and the database is said to be more or less tested, everything should be OK, although I didn't have the time to try this myself yet. You can find the parameters in the beginning of the .vps files, where ADPACK (Ozaki's pseudo generation program) dumps the whole input file. If anything is unclear, you can simply consult the ADPACK manual. Just take the radii and run ATOM with them, or, even better, use the Octopus ( www.tddft.org) web interface for generation of pseudos with ATOM, it's quite convenient. 2006/12/13, Oleksandr Voznyy [EMAIL PROTECTED]: The important thing is to take cutoff radii somewhere close to the wavefunction maximum. The LDA and GGA wavefunctions won't differ that much in terms of maxima positions. So LDA input would be a good starting point for GGA pp generation. If you are talking about NLCC core radii, I suggest you to verify it yourself by looking at core charge, all-electron charge and pseudo charge plots. The NLCC core radii in some pseudos in the database are just non-sensical. -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Construction of GGA pseudopotential from LDA inputdata
Dear Vasilii, thank you for the information. Yes, there are some input file templates available together with ADPACK sources, so I can take cutoff radii. Unfortunately, not all the elements I need are available. I put below the link for other users to make use of this: http://staff.aist.go.jp/t-ozaki/adpack/adpack.html On 16/12/06, Vasilii Artyukhov [EMAIL PROTECTED] wrote: I think that you could use the radii from Dr. Ozaki's database of pseudopotentials for OpenMX. Since the method is essentially the same, and the database is said to be more or less tested, everything should be OK, although I didn't have the time to try this myself yet. You can find the parameters in the beginning of the .vps files, where ADPACK (Ozaki's pseudo generation program) dumps the whole input file. If anything is unclear, you can simply consult the ADPACK manual. Just take the radii and run ATOM with them, or, even better, use the Octopus ( www.tddft.org) web interface for generation of pseudos with ATOM, it's quite convenient. 2006/12/13, Oleksandr Voznyy [EMAIL PROTECTED]: The important thing is to take cutoff radii somewhere close to the wavefunction maximum. The LDA and GGA wavefunctions won't differ that much in terms of maxima positions. So LDA input would be a good starting point for GGA pp generation. If you are talking about NLCC core radii, I suggest you to verify it yourself by looking at core charge, all-electron charge and pseudo charge plots. The NLCC core radii in some pseudos in the database are just non-sensical. -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
[SIESTA-L] Construction of GGA pseudopotential from LDA input data
Dear SIESTA users! Has anyone had an experience of constructing ATOM input for GGA pseudopotential from the input data for LDA pseudo? For example, on SIESTA web page there are LDA pseudos for most elements, but no GGA pseudos. Can I use the input data for the LDA pseudo from SIESTA page to construct GGA pseudo? I'm interested, if I should change core radii and in what way. Thanks in advance -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Pseudos from ABINIT
Vasiliy, also this page will be of use for you to generate a pseudo (instead of running ATOM in console env.): http://www.tddft.org/programs/octopus/pseudo.php Actually, you'll need to set proper core radii for each type of the orbital. And you may use the values from ABINIT webpage. But as I wrote before, for most pseudos the default value defined somewhere in FHI98PP code, is used (I mean GGA pseudos), so abinit page is of no use. For LDA pseudos core radii are defined, you may take that values and generate an LDA pseudo from tddft page or ATOM. Look at the beginning of pseudo file: ftp://ftp.abinit.org/pub/abinitio/Psps/LDA_TM.psps/40/40zr.pspnc (for Zr) rcpsp - is what exactly you need. You may also use this page to find core radii, but I don't know if they are good for TM pseudos: http://www.pwscf.org/pseudo.htm On 01/12/06, Vasilii Artyukhov [EMAIL PROTECTED] wrote: Well, I've browsed back through the list archives, I think, up to June or something, but perhaps the discussion you refer to has escaped from my attention. Of course, you can always take the pseudopotenital generation parameters from some other source and generate them - but then, why did they mention ABINIT and no other code? It turns out that ABINIT pseudos are by no way better suitable for SIESTA than any other psudo format! What I'm pretty sure about is that there's some XML pseudopotential format that is readable by both codes, but it isn't documented yet. Does anybody have a clue on how to use that? 2006/12/1, Marcos Verissimo Alves [EMAIL PROTECTED]: They can, but not with a direct copy from the abinit pseudos website. If you manage to get the rc's from the output/input files at the abinit website, it's just a matter of setting the rc's in the .inp files for the ATOM program and generate your own. In the siesta webpage there is a link saying that the pseudos from abinit can be used with siesta, but this is correct only in the sense that they are troullier-martins norm-conserving pseudos, which siesta does use. Or, if you write your own conversion program, you can convert the formats, if possible. This subject has just been discussed a few weeks ago and before that, some months ago, in this very mailing list. Sometimes it's worth checking the mailing list archives for the answer before posting a technical question. In the process, you might even learn some spanish, which doesn't really hurt at all... :) To developers and maintainers: maybe a FAQ/wiki, could be written and published both in the manual (FAQ only) and website (FAQ/wiki)? If someone sets up the wiki site, I can write some entries for these technical issues, in my totally spare time... :)) Cheers, Marcos Hello everyone, I recall reading something about the fact that the pseudos from the ABINIT database could somehow be used with SIESTA, but I can't find that bit now. Is it just false memory, or is it really possible to do that? I also found out that both codes can read pseudos in XML format, but neither ABINIT nor SIESTA documentation have any info on that. Does anyone have a clue? Regards, Vasilii -- 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! -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Zr and Y pseudopotentials needed
Dear Dr. Verissimo Alves! Thank you for your answer. Unfortunately, It is not clear for me, where to find core radii. For example, this is exactly the pseudo I need: ftp://ftp.abinit.org/pub/abinitio/Psps/GGA_FHI/40-Zr.GGA.fhi And the corresponding ini file: ftp://ftp.abinit.org/pub/abinitio/Psps/GGA_FHI/40-Zr.GGA.ini It seems, that core radii are not given at all. On 28/11/06, Marcos Verissimo Alves [EMAIL PROTECTED] wrote: Hello, SIESTA users! I'd be grateful if any of you can provide me a good GGA pseudopotential for Yttrium (Y), and also for Zirconium (Zr). There are some at ABINIT web page, but I don't know how to convert those pseudos to SIESTA psf/vps format. Is there any software for doing it? It would be sooo nice if there were... Anyway, you can always get the core radii from the pseudos in abinit's webpage, insert them in an .inp file and generate your own with ATOM. Marcos -- Yurko Natanzon PhD Student Henryk Niewodnicza?ski Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] -- 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! -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED] ICQ 132796386
[SIESTA-L] Zr and Y pseudopotentials needed
Hello, SIESTA users! I'd be grateful if any of you can provide me a good GGA pseudopotential for Yttrium (Y), and also for Zirconium (Zr). There are some at ABINIT web page, but I don't know how to convert those pseudos to SIESTA psf/vps format. Is there any software for doing it? -- Yurko Natanzon PhD Student Henryk Niewodniczański Institute of Nuclear Physics Polish Academy of Sciences ul. Radzikowskiego 152, 31-342 Kraków, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
