Re: [SIESTA-L] Another compilation trouble - or is it?
Let's say that this corrects the problem *partially*. The graphite calculation is ok, but in some other cases, this doesn't help, and that still includes the BaTiO3 test. So it appears that I have to recompile the program from scratch. But it would still be interesting to know the possible sources of this error. Thanks everyone! Vasilii 2006/12/7, Oleksandr Voznyy <[EMAIL PROTECTED]>: There is a reported problem with SIESTA, which is actually related to the problems in math libraries that DivideAndConquer doesn't work correctly. Try to set DivideAndConquer False. Is it your case? > Error in Cholesky factorisation in cdiag
Re: [SIESTA-L] Another compilation trouble - or is it?
It is definitely a problem with your compilation. siesta works fine for me on all machines at JSCC. >Well, I'm quite sure that the OS on that computer has been reinstalled this >spring, so it's unlikely that something is outdated. I'm not sure if the >compilation options were exactly the same, I'll have to check it. What I'm >sure about is that it's not a problem of the OS or MPICH or something like >that, it's just that I did something wrong. > >2006/12/7, Sebastien LeRoux <[EMAIL PROTECTED]>: >> >> Dear Vasilii, >> >> I had this problem few weeks ago running CG calculations on GeS2, >> I solved it first by checking that all lib and code (lapack, blas, >> scalapack, blacs, mpich(c-part, f90-part), siesta) >> have been compiled using exactly the same compilation options. If >> already done then you may have to update >> general lib and tool on your system (glibc, gnu binutils, gnu make ... I >> had an old Kernel (2.4.7) >> and old lib/tools on my system) ... That is indeed a problem of >> compilation, but I think >> that somehow the intel compilers v9 and/or the pre-compilation utilities >> (make, configure ...gnu binutils in general) are using 'recent' options >> and/or lib which may not be >> undestood by old versions and so not applied. >> Then you will have to recompile everything. >> If you are working (as I understand) on a pentium 4 arch system you can >> use exactly >> the same options I used in my guide and be shure it works fine. >> >> >> Sйbastien Le Roux >> >> PS: In my case the error in the Cholesky diagonalistion was due to the >> explosion (there is no >> other word) of one force in the caclulation. You can check it few steps >> before the break, >> if one component of the forces is increasing too much (in my case from >> 0.05 ev/A to ~50 eV/A >> in 4 steps !!!) >> >> -- >> >> 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 >> >>
Re: [SIESTA-L] Another compilation trouble - or is it?
There is a reported problem with SIESTA, which is actually related to the problems in math libraries that DivideAndConquer doesn't work correctly. Try to set DivideAndConquer False. Is it your case? Error in Cholesky factorisation in cdiag
Re: [SIESTA-L] Another compilation trouble - or is it?
Well, I'm quite sure that the OS on that computer has been reinstalled this spring, so it's unlikely that something is outdated. I'm not sure if the compilation options were exactly the same, I'll have to check it. What I'm sure about is that it's not a problem of the OS or MPICH or something like that, it's just that I did something wrong. 2006/12/7, Sebastien LeRoux <[EMAIL PROTECTED]>: Dear Vasilii, I had this problem few weeks ago running CG calculations on GeS2, I solved it first by checking that all lib and code (lapack, blas, scalapack, blacs, mpich(c-part, f90-part), siesta) have been compiled using exactly the same compilation options. If already done then you may have to update general lib and tool on your system (glibc, gnu binutils, gnu make ... I had an old Kernel (2.4.7) and old lib/tools on my system) ... That is indeed a problem of compilation, but I think that somehow the intel compilers v9 and/or the pre-compilation utilities (make, configure ...gnu binutils in general) are using 'recent' options and/or lib which may not be undestood by old versions and so not applied. Then you will have to recompile everything. If you are working (as I understand) on a pentium 4 arch system you can use exactly the same options I used in my guide and be shure it works fine. Sébastien Le Roux PS: In my case the error in the Cholesky diagonalistion was due to the explosion (there is no other word) of one force in the caclulation. You can check it few steps before the break, if one component of the forces is increasing too much (in my case from 0.05 ev/A to ~50 eV/A in 4 steps !!!) -- 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
Re: [SIESTA-L] Another compilation trouble - or is it?
Dear Vasilii, I had this problem few weeks ago running CG calculations on GeS2, I solved it first by checking that all lib and code (lapack, blas, scalapack, blacs, mpich(c-part, f90-part), siesta) have been compiled using exactly the same compilation options. If already done then you may have to update general lib and tool on your system (glibc, gnu binutils, gnu make ... I had an old Kernel (2.4.7) and old lib/tools on my system) ... That is indeed a problem of compilation, but I think that somehow the intel compilers v9 and/or the pre-compilation utilities (make, configure ...gnu binutils in general) are using 'recent' options and/or lib which may not be undestood by old versions and so not applied. Then you will have to recompile everything. If you are working (as I understand) on a pentium 4 arch system you can use exactly the same options I used in my guide and be shure it works fine. Sébastien Le Roux PS: In my case the error in the Cholesky diagonalistion was due to the explosion (there is no other word) of one force in the caclulation. You can check it few steps before the break, if one component of the forces is increasing too much (in my case from 0.05 ev/A to ~50 eV/A in 4 steps !!!) -- 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
