Hi, By the way, I've just found some more interesting 'features' of SIESTA + Intel (the BaTiO3 test). When I turn off Diag.Use2D, this Cholesky (what does that stand for, anyway?) error disappears, but the first SCF iteration seems to last forever. Weird.
Yes, the calculations do run without any warnings on an IBM cluster (XL compilers), and yes there are sometimes issues with convergence, I've reported them on the list the other day - I think we have similar problems. The same systems converge with no problem at all on the Intel machine (when there's no Cholesky error), so there must be some troubles with the XL compilers, too - or either I'm the one responsible for that, but that would mean that I'm not alone since you have this problem, too :) For the unlucky cases where there are troubles on both clusters, I guess I'll have to use OpenMX for now, since they're too big for a planewave code... 2007/5/17, Marcos Verissimo Alves <[EMAIL PROTECTED]>:
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!
