Re: [SIESTA-L] Follow-up on NaN error with parallel version of Siesta 2.0
Hi Derek, I haven't tried with lam-mpi, but with intel mpi there are problems if you link with a blacs compiled for mpi 1.2 while using mpi 2 (lam-mpi implements almost all of mpi 2). The problem is in one of the include files of the c interface of blacs, so it can be really difficult to detect while using a fortran only application. In order to link with mkl I'm using the following: GUIDE=/opt/intel/cmkl/8.1.1/lib/em64t/libguide.a SCALAPACK=/opt/intel/cmkl/8.1.1/lib/em64t/libmkl_scalapack.a #Pay attention to the intelmpi20 suffix of blacs: BLACS=/opt/intel/cmkl/8.1.1/lib/em64t/libmkl_blacs_intelmpi20.a VML=/opt/intel/fce/9.1/lib/libsvml.a LAPACK=/opt/intel/cmkl/8.1.1/lib/em64t/libmkl_lapack.a BLAS=/opt/intel/cmkl/8.1.1/lib/em64t/libmkl_em64t.a LIBS=$(SCALAPACK) $(BLACS) $(LAPACK) $(BLAS) $(GUIDE) $(VML) -lpthread Also if nuotot is only 24 then the system is really small, maybe there are no orbitals in a given node and it produces the NaN. Good luck, and please post your findings! Eduardo On oct 5, 2006, at 5:32 PM, Derek A. Stewart wrote: Hi everyone, Just a quick follow up on the NaN errors I have been running into with Siesta 2.0. It looks like the error occurs in the cdiag subroutine (cdiag.F) when pzheevd is called to solve the standard eigenvalue problem. I have tried changing the parameters of the run (i.e. DivideConquer, Set2D), but similar problems occur. This means it is probably a problem with the scalapack library. Has anyone successfully compiled the parallel version of Siesta with lam-mpi 7.1.1 with intel compilers version 8 or 9? If they have, I would be interested in comparing your Bmake, SLmake input files for BLACS and SCALAPACK with what I am using. Thanks, Derek On 10/4/06, Derek A. Stewart [EMAIL PROTECTED] wrote: Hi all, I have been trying to get the parallel version of Siesta 2.0 to run with the intel compilers (version 8.1, MKL math libraries) and lam-mpi (7.1.1). I have no problems compiling the parallel version of siesta. However, when I run a calculation, I run into a problem which I have traced to the diagk.F file. Evidently the psi matrix psi(2,nuotot,nuo) which provides auxiliary space for the eigenvectors has NaN entries for nuo=1,2. The other entries (nuo=3-24) are fine. This can probably be traced to the cdiag subroutine called in this file and I am working on this. Has anyone run into this problem before? For my compilation, it appears to occur for general input files. The run has no problems for the serial case. Thanks, Derek ### Derek Stewart, Ph. D. 250 Duffield Hall Cornell Nanoscale Facility stewart (at) cnf.cornell.edu (607) 255-2856
Re: [SIESTA-L] Follow-up on NaN error with parallel version of Siesta 2.0
Hi Derek, Did you try to use scalapack/blacs shipped with CMKL library? sergey Hi everyone, Just a quick follow up on the NaN errors I have been running into with Siesta 2.0. It looks like the error occurs in the cdiag subroutine (cdiag.F) when pzheevd is called to solve the standard eigenvalue problem. I have tried changing the parameters of the run (i.e. DivideConquer, Set2D), but similar problems occur. This means it is probably a problem with the scalapack library. Has anyone successfully compiled the parallel version of Siesta with lam-mpi 7.1.1 with intel compilers version 8 or 9? If they have, I would be interested in comparing your Bmake, SLmake input files for BLACS and SCALAPACK with what I am using. Thanks, Derek On 10/4/06, Derek A. Stewart [EMAIL PROTECTED] wrote: Hi all, I have been trying to get the parallel version of Siesta 2.0 to run with the intel compilers (version 8.1, MKL math libraries) and lam-mpi (7.1.1). I have no problems compiling the parallel version of siesta. However, when I run a calculation, I run into a problem which I have traced to the diagk.F file. Evidently the psi matrix psi(2,nuotot,nuo) which provides auxiliary space for the eigenvectors has NaN entries for nuo=1,2. The other entries (nuo=3-24) are fine. This can probably be traced to the cdiag subroutine called in this file and I am working on this. Has anyone run into this problem before? For my compilation, it appears to occur for general input files. The run has no problems for the serial case. Thanks, Derek ### Derek Stewart, Ph. D. 250 Duffield Hall Cornell Nanoscale Facility stewart (at) cnf.cornell.edu (607) 255-2856
Re: [SIESTA-L] pseudopotential problem
Hi, I would add the following option to what Marcos says: You can start with a standard atom inp file. See the atom manual for details. Then do an all electron calculation with atm. So you really want an ae.inp kind of file. Keep in mind, atm, unlike siesta, has a very *rigid* readout format, so *keep all spacings in your input files as in the template ae.inp file* that you can get, for instance on the Tutorial directory of atom. Otherwise you will get all kind of errors during the ae.sh script run. Once you have a successful atm calculation, go to your Bi.ae.inp directory, that will be created if a successful run did happen, and opent the OUT file. In this file you will have a bunch of data. Go to the channels you want your pseudo to have and dismiss the previous channels (you get all channels here 'cause this is an all-electron calculation). Check the biggest r extr for the channels you are interested in. For instance, from one of my files: . . . n = 5 l = 1 s = 0.5 a extr 0.290 -0.408 0.601 -1.120 b extr-0.055 0.022 -0.013 0.008 r extr 0.037 0.138 0.351 0.979 r zero 0.075 0.216 0.528 r 90/99 % 1.597 2.266 . . . (and assuming I wanted the 5p orbital to be in the valence) I would write down 0.97 as a starting point for my rc in my pseudo. You get the idea. Please PLOT the radial part of your all electron result. Your rc must be away enough from parts where your wavefunctions cross the r axis (ie, bigger than the biggest r zero value). Okay, suppose you wrote down your r extrs. Now take a template pg (or pe for that matter) file. Replace the rcs in that file (and the atomic number as well as the pseudo flavor to suit!) by the ones you just got. Sometimes is safe to choose one of your r_extrs for all rcs (the smallest, the biggest, some value in between,...) Run the pg.sh script. Go back to your output dir (something like Bi.pe.inp) and plot the wavefuncions once more. pg(pe) wavefunctions should overlap outside rc. On a more stringent test of your pseudo, you can check in the atom manual how to test for transferability. All this is good but, -sometimes atm changes your input radii (See OUT file for actual taken values). -even though you are happy with your pseudo, siesta discovers GHOST states (...and crashes). Then you have to go back to your pseudo inp file and modify some options slightly. -if your pseudo makes for a sucessful siesta run, do *check* some bulk properties: Lattice constants and the like. Bottom line is, it will take you a couple of days to get comfortable with the process of generating pseudos but it is worth (and perhaps even necessary if you consider using SIESTA in the long run) the effort. Best regards, Salvador. On Thursday 05 October 2006 09:08, Marcos Verissimo Alves wrote: Hi Bozo, Hi Marcos thanks for your mail and sorry for not giving full information, I just wanted to keep mail as short as possible so people can go quickly through it. Don't keep the e-mail short when you have a problem whose cause you cannot identify. In some cases, a more lengthy (but not too lengthy) explanation is necessary, in order to identify possible sources of error. So, what I did is: I went to SIESTA webpage, then to LINKS and there you can find ABINIT with the list of pseudopotentials that Siesta can use. So I simply downloaded GGA (PBE) Hartwigsen_Goedecker-Hutter pseudopotentil for Bi as a text file. I named it Bi.psf. So there is your problem. If you look at the abinit pseudopotential format and the .psf format, you will see that they are completely different. What the link means is that siesta can use thses potentials because they are norm-conserving, but they have to be in the appropriate format. If you can find (or anyone in the list can provide) a format conversion tool from the abinit format to the siesta format, it will be great. Otherwise, you can do: a) See if, in the abinit file, the core radii are specified. I don't remember if siesta has HGH pseudopotential generation (probably not), but you could use the rc's from HGH as a starting point for generating your own TM GGA pseudo using atom, testing it on elemental Bi. If this is not good, you can do b) a search in the literature, find some paper with calculations for Bi which states the channels and core radii for the GGA TM pseudopotential are used, and generate your own pseudo from those. Or, c) you could ask, on the list, if anyone has a good pseudo for Bi. I had pseudopotential for Si from before. And then started simulation. I know that pseudopotential for Si is ok, because I did some calculations with silicon in diamond before, and everything worked fine. Probably because the pseudo was in the right file format (.psf). In simulation I am using generalized gradient approximation and also PBE parametrization of the
Re: [SIESTA-L] probleme_with_phenol_input
| Error in Cholesky factorisation in rdiag | Stopping Program from Node:0 | | I don't know what is exactly the problem ? A good chance that it is due to an error in input, e.g. two atoms at the same place Good luck, Andrei Postnikov +-- Dr. Andrei Postnikov Tel. +33-387315873 - mobile +33-666784053 ---+ | Paul Verlaine University - Institute de Physique Electronique et Chimie, | | Laboratoire de Physique des Milieux Denses, 1 Bd Arago, F-57078 Metz, France | +-- [EMAIL PROTECTED] http://www.home.uni-osnabrueck.de/apostnik/ --+
[SIESTA-L] probleme_with_phenol_input
Dear SIESTA users, I'm a new user of SIESTA and I try to run some little input in order to learn SIESTA. I have a problem with a calculation of a phenol molecule. Here is the end of my output : outcell: Unit cell vectors (Ang): 11.6817490.000.00 0.00 11.6817490.00 0.000.00 13.076909 outcell: Cell vector modules (Ang) : 11.681749 11.681749 13.076909 outcell: Cell angles (23,13,12) (deg): 90. 90. 90. outcell: Cell volume (Ang**3): 1784.5177 InitMesh: MESH =80 x80 x90 = 576000 InitMesh: Mesh cutoff (required, used) = 120.000 129.618 Ry * Maximum dynamic memory allocated =25 MB Error in Cholesky factorisation in rdiag Stopping Program from Node:0 I don't know what is exactly the problem ? Thanks in advance Cornild David University of Mons-Hainaut Belgium - Découvrez un nouveau moyen de poser toutes vos questions quel que soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. Cliquez ici.
Re: [SIESTA-L] pseudopotential problem
Hi Bozidar, That really depends on the kind of error you are obtaining on the reading of the pesudo by siesta. There are several points in which your e-mail provides incomplete information: 1) Have you downloaded the pseudopotential itself? If it's giving an error, then it might be corrupted. Difficult to happen, but could be. 2) Have you downloaded the input file and then generated the pseudo using atom? If so, then you may (inappropriately) be getting ghost states and this is the kind of error Chun is referring to; it has been discussed on the list a while ago. If this is the case (ghost states from a pseudo which is known to have none), then you should recompile atom with a good compiler (intel is very good), with -O2 optimization, and NOT -O3, which is known to, in some cases, induce to numerical errors. So, to really help you, you should provide more information on what you have actually done. Best regards, Marcos Hi, I think you must have used the different compilers to make the siesta and the atom. You can recompile the atom using the same compiler you used to make siesta, than generate the pseudopotential again. Good luck. Chun - Original Message - From: Bozidar Butorac [EMAIL PROTECTED] To: SIESTA-L@listserv.uam.es Sent: Thursday, October 05, 2006 4:48 PM Subject: [SIESTA-L] pseudopotential problem Dear Siesta users I started calculation about Bismuth in Silicon. I downloaded pseudopotential for Bi from the SIESTA webpage, but after siesta reads input file, the calculation suddenly stops when the pseudopotentil for Bi is being read. I know that pseudopotential for Si is ok, because I did some simulations involving silicon before and everything was good. I think the problem is about the format of pseudopotential file for Bi, but I don't know how to fix it. Does anybody have an idea how to solve it? I also attached the output file. Thank you very much in advance. Cheers, Bozo -- 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!
[SIESTA-L] pseudopotential problem
Dear Siesta users I started calculation about Bismuth in Silicon. I downloaded pseudopotential for Bi from the SIESTA webpage, but after siesta reads input file, the calculation suddenly stops when the pseudopotentil for Bi is being read. I know that pseudopotential for Si is ok, because I did some simulations involving silicon before and everything was good. I think the problem is about the format of pseudopotential file for Bi, but I don't know how to fix it. Does anybody have an idea how to solve it? I also attached the output file. Thank you very much in advance. Cheers, Bozo Taking nodenames from /home/bozidar/Marshall/Bi_in_Si/244.node00.kcl.ac.uk.conf, number of nodes specified by -np /opt/scali/bin/mpimon -stdin all /home/bozidar/bin/siesta -- n02 1 n02 1 SIESTA 1.3-- [Release] (30 Jul 2003) Architecture : pgf90-mpich Compiler flags: mpif90 -fast PARALLEL version * Running on2 nodes in parallel Start of run: 5-OCT-2006 7:28:58 *** * WELCOME TO SIESTA * *** WARNING: Siesta is reading its input from file INPUT_DEBUG ** Dump of input data file # Label SystemLabel Bi_in_Si # Optimisation MD.TypeOfRun CG MD.NumCGSteps 150 MD.MaxForceTol 0.01 eV/Ang MD.VariableCell true MD.MaxStressTol 100 bar # SCF SolutionMethod diagon kgrid_cutoff 1.0 Ang MaxSCFIterations 200 DM.MixingWeight 0.10 DM.NumberPulay 3 SpinPolarized false # Basis set MeshCutoff 170 Ry PAO.EnergyShift 0.01 Ry PAO.BasisSize DZP #PAO.SplitNorm 0.15 # Functional XC.Functional GGA XC.Authors PBE # I/O LongOutput true UseSaveData false NumberOfSpecies 2 NumberOfAtoms 64 %block ChemicalSpeciesLabel 1 14 Si 2 83 Bi %endblock ChemicalSpeciesLabel LatticeConstant1.0 Ang %block LatticeVectors 11.0430140.00 0.00 0.0011.043014 0.00 0.00 0.00 11.043009 %endblock LatticeVectors AtomicCoordinatesFormat Ang %block AtomicCoordinatesAndAtomicSpecies -0.0567 -0.0859 -0.2005 1 # Si 1 1.380382351.380378231.38036897 1 # Si 2 2.760758482.76075650 -0.1971 1 # Si 3 4.141121824.141122501.38037668 1 # Si 4 -0.07752.760756062.76075324 1 # Si 5 1.380386384.141122884.14112765 1 # Si 6 2.76075870 -0.11452.76075387 1 # Si 7 4.141122201.380382664.14112805 1 # Si 8 5.52150958 -0.1113 -0.1881 1 # Si 9 6.901887851.380375211.38036817 1 # Si10 8.282252162.76075320 -0.2085 1 # Si11 9.662616254.141120391.38037155 1 # Si12 5.521511762.760752772.76075210 1 # Si13 6.901891504.141121114.14112799 1 # Si14 8.28225312 -0.14672.76075230 1 # Si15 9.662614361.380379474.14112697 1 # Si16 -0.08105.52151198 -0.1950 1 # Si17 1.380379226.901891041.38036724 1 # Si18 2.760754868.28225329 -0.2255 1 # Si19 4.141121049.662614561.38036914 1 # Si20 -0.10738.282253702.76075032 1 # Si21 1.380383589.662612584.14112543 1 # Si22 2.760755455.521513472.76075143 1 # Si23 4.141121296.901892614.14112751 1 # Si24 5.521508225.52150909 -0.1749 1 # Si25 6.901887146.901890421.38036878 1 # Si26 8.282249168.28224996 -0.2361 1 # Si27 9.662615849.662613541.38036341 1 # Si28 5.521508668.282250812.76074921 1 # Si29 6.901887429.662611614.14112649 1 # Si30 8.282250615.521510382.76074955 1 # Si31 9.662613266.901890364.14112617 1 # Si32 -0.0608 -0.09945.52151657 1 # Si33 1.380380871.380375956.90189628 1 # Si34 2.760756952.760753625.52152168 1 # Si35 4.141123294.141121756.90189933 1 # Si36 -0.08932.760753408.28225115 1 # Si37 1.380386734.141119879.66260137 1 # Si38 2.76075754 -0.14568.28225184 1 # Si39 4.141121541.380380479.66260173 1 # Si40 5.52150922 -0.12495.52151529 1 # Si41 6.901885831.380372506.90189468 1 # Si42 8.282251182.760750185.52152044 1 # Si43 9.662615574.141120726.90189703 1 # Si44 5.521510482.760750718.28225032 1 # Si45 6.901886824.141123439.66260728 1 # Si46 8.28225125
