Hi Vasilii, Actually, as far as I can see, it is either the fault of scalapack, or bad compilation of the latter. Right now I am running a MD simulation for a molecule using the SingleExcitation feature of siesta, and I have had the opportunity of fall victim of the Cholesky error even in non-spin-polarized calculations. The reason I believe it could be an error caused by scalapack is that:
1) Both in my laptop and a pc cluster (intel 9/8.1 + mkl 9.0), the parallel calculation gves the Cholesky error. This is independent of the scalapack version I use, 1.7 (that has lapack/blas routines hard-coded into it) or 1.8 (which, in my case, uses the mkl instead of the hard-coded lapack/blas). 2) Going to IBM SP5 processors, I have run parallel siesta using the computing facility's pre-built scalapack and essl/pessl. No Cholesky error, but I got weird behavior with respect to the scf convergence: it gets stuck in a low value (say, 0.0002 or 0.0001), and goes on indefinitely. However, when I run a fully-serial version of siesta compiled with the xlf95 + essl, no error, no getting stuck in the scf, and the numbers are similar to those I obtain with intel 9.1/mkl 9.0 fully serial versions in my laptop. These errors severely limit the use of siesta for interesting large systems, even if you have access to a facility with a lot of memory. I wonder if ther would be a way of running parallel siesta without scalapack. Marcos > Hi, > > About the Cholesky bug: I've fallen its victim, too, running parallel > SIESTA > compiled with ifort 9. However, in my case everything would work when I > turned off the parallelization over k-points. I don't get this error on an > IBM machine with the XL compilers, so the bug seems related to the Intel > compiler. I've tried both MKL and the usual BLAS/LAPACK, it seems the > libraries are not guilty of this. I also tried different levels of > optimization (including zero) for cdiag.f, didn't help either. So it would > be extremely nice if someone from the developers side could take a look and > tell us how to compile SIESTA on parallel Intel clusters with ifort so that > everything works properly. > > 2007/5/10, Marcos Verissimo Alves <[EMAIL PROTECTED]>: > >> Hi Mousumi, >> >> > 1. Presently I'm doing some spin-plarized relaxation calculations using >> > only the option "SpinPolarized yes". But, I will like to do the >> > calculations with fixed spins on each atom. How to fix spins in SIESTA >> and >> > run relax/scf calculations? >> >> Check the flags FixSpin, TotalSpin and DM.InitSpin, in the siesta manual. >> I guess they will do what you want. >> >> > >> > 2. I need to calculate magnetic moment and spin-dependent electronic >> DOS >> > of my system of study after fixing the spins properly. Could someone >> guide >> > as to how we calculate magnetic moment in SIESTA. An input file and, >> > output file will be very helpful. >> >> Either I haven't understood what you want, or I am very wrong; but if you >> fix the spins on the atoms, you have already determined the magnetic >> moment beforehand, haven't you? The magnetic moment is given at the end >> of >> your calculation by Qup-Qdown. >> >> With regards to the spin-dependent DOS, you can calculate it in two ways. >> One of them is using the eig2dos.f program, in the Util directory of >> siesta. It will calculate the DOS from the eigenvalues, contained in the >> EIG file. Another one, more expensive, but good if you want to see the >> constributions of different orbitals and even from individual atoms, is >> to >> calculate the Projected Density of States (check for the flag >> ProjectedDensityOfStates in the manual). It will calculate the PDOS >> **and** DOS. >> >> Since we are speaking of noncollinear spin calculations, I would like to >> call the developers' attention to a bug in the noncollinear spin >> calculations. I was doing some tests for noncollinear spin calculations, >> and I ran into two bugs. One happens in parallel runs, the other in >> serial >> runs. >> >> Before anything, my compilations: >> >> 1) Parallel: compiler: ifort 9, mpich - myrinet version at CINECA and >> also >> my own compiled latest version in a dual-core turion -, mpi scalapack and >> blacs compiled from scratch. Also the latest version of scalapack, 1.8, >> which I compiled and tested a few minutes ago at CINECA. Intel serial mkl >> libraries - CINECA doesn't seem to have the cluster version of the mkl. >> >> 2) Serial: ifort 9 and mkl. Both versions of siesta are compiled with >> -DWXML_INIT_FIX flag. >> >> The bug in parallel runs is one that has come up so many times in the >> list, the "error in Cholesky factorization", in cdiag.f . It happens for >> the prosaic molecule O2, but also happens for the (also prosaic) ptn with >> 2 atoms in the unit cell. I have not tried running it for a larger >> system. >> >> The Cholesky error disappears when I run the calculations with a fully >> serial version of siesta, compiled without mpi, scalapack and so on. >> However, it crashes when, at the end of the first SCF step, it tries to >> write the data to the xml file. It says that a certain unit is already >> open, and stops there. I'll be glad to provide all pseudo, fdf and >> makefiles, plus the procedures I used to compile each of the versions, if >> this is necessary to reproduce the mistake. >> >> Cheers, >> >> Marcos >> >> >> -- >> Dr. Marcos Verissimo Alves >> Post-Doctoral Fellow >> Condensed Matter and Statistical Physics Sector >> International Centre for Theoretical Physics >> Trieste, Italy >> >> -------- >> >> I have become so addicted to vi that I try to exit OpenOffice by typing >> :wq! >> > -- Dr. Marcos Verissimo Alves Post-Doctoral Fellow Condensed Matter and Statistical Physics Sector International Centre for Theoretical Physics Trieste, Italy -------- I have become so addicted to vi that I try to exit OpenOffice by typing :wq!
