Re: [SIESTA-L] compile error of parallel version
Hi, Latest version of MKL (10.X) contains scalapack/blacs. Why don't you use it? It has better performance than netlib libraries. Sergey 28.05.08, 20:20, Chol-Jun Yu [EMAIL PROTECTED]: Hello, users, I used really mpiifort for blacs, scalapack, blas, lapack and siesta. Then still two undefined ... were remained. /home/cy849828/BLACS/LIB/blacsCinit_MPI-LINUX-0.a(blacs_pinfo_.o): In function `blacs_pinfo_': blacs_pinfo_.c:(.text+0x75): undefined reference to `bi_f77_get_constants_' /home/cy849828/BLACS/LIB/blacsCinit_MPI-LINUX-0.a(Cblacs_pinfo.o): In function `Cblacs_pinfo': blacs_pinfo_.c:(.text+0x75): undefined reference to `bi_f77_get_constants_' make: *** [siesta] Error 1 Hope your again hints, Chol-Jun Eduardo Anglada wrote: Hi, You have to use mpiifort for blacs, scalapack and siesta. Regards, Eduardo / On 28/05/2008, at 15:32, Chol-Jun Yu wrote: Dear Eduardo, I used mpif77 as compiler for blacs and scalapack, and mpiifort for siesta, which you can see in attaches. Still the undefined ... borders me. Could you give me again comments? With kind regards, Chol-Jun Eduardo Anglada wrote: Hi, You compiled blacs and scalapack with gfortran or g77, while siesta was compiled with ifort (intel fortran). You shouldn't mix compilers. Regards, Eduardo On 28/05/2008, at 9:11, Chol-Jun Yu wrote: Hello, during the compilation of parallel version, the following errors were appeared, ... cdiag.o: In function `cdiag': /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:234: undefined reference to `blacs_get_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:235: undefined reference to `blacs_gridinit_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:243: undefined reference to `blacs_get_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:244: undefined reference to `blacs_gridinit_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:246: undefined reference to `blacs_gridinfo_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:321: undefined reference to `blacs_gridinfo_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:325: undefined reference to `blacs_gridinfo_' rdiag.o: In function `rdiag': /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:226: undefined reference to `blacs_get_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:227: undefined reference to `blacs_gridinit_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:235: undefined reference to `blacs_get_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:236: undefined reference to `blacs_gridinit_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:238: undefined reference to `blacs_gridinfo_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:304: undefined reference to `blacs_gridinfo_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:306: undefined reference to `blacs_gridinfo_' /home/cy849828/scalapack-1.8.0/libscalapack.a(pxerbla.o): In function `pxerbla_': pxerbla.f:(.text+0x3c): undefined reference to `s_wsfe' pxerbla.f:(.text+0x52): undefined reference to `do_fio' pxerbla.f:(.text+0x68): undefined reference to `do_fio' pxerbla.f:(.text+0x79): undefined reference to `do_fio' pxerbla.f:(.text+0x8d): undefined reference to `do_fio' pxerbla.f:(.text+0x94): undefined reference to `e_wsfe' /home/cy849828/scalapack-1.8.0/libscalapack.a(pdgemr.o): In function `Cpdgemr2do': ... I have attached the arch.make file. Any comment will be thankful. Chol-Jun -- # # This file is part of the SIESTA package. # # Copyright (c) Fundacion General Universidad Autonoma de Madrid: # E.Artacho, J.Gale, A.Garcia, J.Junquera, P.Ordejon, D.Sanchez- Portal # and J.M.Soler, 1996-2006. # # Use of this software constitutes agreement with the full conditions # given in the SIESTA license, as signed by all legitimate users. # .SUFFIXES: .SUFFIXES: .f .F .o .a .f90 .F90 SIESTA_ARCH=x86_64-unknown-linux-gnu--Intel FPP= FPP_OUTPUT= FC=mpiifort RANLIB=ranlib SYS=nag SP_KIND=4 DP_KIND=8 KINDS=$(SP_KIND) $(DP_KIND) FFLAGS=-g FPPFLAGS= -DMPI -DFC_HAVE_FLUSH -DFC_HAVE_ABORT LDFLAGS= ARFLAGS_EXTRA= FCFLAGS_fixed_f= FCFLAGS_free_f90= FPPFLAGS_fixed_F= FPPFLAGS_free_F90= BLAS_LIBS=-lblas LAPACK_LIBS=-llapack BLACS_LIBS=/home/cy849828/BLACS/LIB/blacs_MPI-LINUX-0.a SCALAPACK_LIBS=/home/cy849828/scalapack-1.8.0/libscalapack.a COMP_LIBS=dc_lapack.a NETCDF_LIBS= NETCDF_INTERFACE= LIBS=$(SCALAPACK_LIBS) $(BLACS_LIBS) $(LAPACK_LIBS) $(BLAS_LIBS) $ (NETCDF_LIBS) #SIESTA needs an F90 interface to
Re: [SIESTA-L] LAM SCALAPACK
Cherry,Which fortran compiler do you use? Vasilii is right, it looks like you compiled BLACS using incorrect settings (you can see double underscores in the end of BLACS subroutine, and only one in rdiag). This second underscore comes from BLACS settings (unless you are using g77 compiler). You should always test your own compiled BLACS before using it (there is TESTING directory inside BLACS).By the way, using agressive optimization like -O3 never helps numerical libraries, -O2 is more appropriate.sergey03.06.07, 13:20, Vasilii Artyukhov :It seems to me that whichever MPI youre using is not to blame. Are you sure that you use the correct Fortran/C name conventions? The BLACS distribution, for instance, contains utilities to check the correct settings (in the INSTALL directory).2007/6/3, Cherry Y. Yates [EMAIL PROTECTED]:It doesnt help. I compiled everything with mpif77 -O3 (SIESTA, BLACS, andSCALAPACK), but I still got the same errors. Thanks,Cherry--- Yurko Natanzon [EMAIL PROTECTED] wrote: 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 func tion `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< br /> 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 Krakw, Poland Email: [EMAIL PROTECTED], [EMAIL PROTECTED]Pinpoint customers who are looking for what you sell.http://searchmarketing.yahoo.com/
Re: [SIESTA-L] Problem using latest mkl
Hi Marcos, If you use new intel fortran compiler ( 8.0) and latest mkl ( 8.0), you don't need to use options like '-lpthread -lguide', they will be loaded by compiler. Most important option you have to use in that case is '-openmp' in LD_FLAGS. sergey Ok, forget it... I just realized that I forgot to include -lpthread in the line... Hi all, I have tried to compile siesta 2.0 (serial...) with the new version of the mkl (9.0.018) but, as usual, intel has chenged not only the library names but also the contents of each library. After setting the LIBS line of the arch.make file to -L /opt/intel/mkl/9.0/lib/em64t -lmkl_lapack -lmkl_lapack -lmkl_em64t -lguide -lsvml I get ne final error in the compilation that I simply do not know how to eliminate: /opt/intel/mkl/9.0/lib/emt64t/libguide.so: undefined reference to `pthread_atfork' make: *** [siesta] Error 1 Does anyone know how to eliminate this error with the new mkl? 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!
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] 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
[SIESTA-L] PAO.basis for boron and nitrogen
Dear all, Does anybody have good basis sets for boron and nitrogen? Could anybody share them with me? Thanks a lot, Sergey
[SIESTA-L] using Nose options
Dear Siesters, I am a little confused when perform MD with Nose thermostat. I put TargetTemperature = 500 K but in output file I see the next behaviour: siesta: Temp_ion = 56.381 K siesta: Temp_ion = 39.006 K siesta: Temp_ion = 251.629 K siesta: Temp_ion = 394.578 K siesta: Temp_ion = 216.338 K siesta: Temp_ion = 24.889 K siesta: Temp_ion = 204.911 K siesta: Temp_ion = 416.811 K siesta: Temp_ion = 281.607 K siesta: Temp_ion = 36.181 K siesta: Temp_ion = 58.008 K siesta: Temp_ion = 343.699 K siesta: Temp_ion = 482.636 K siesta: Temp_ion = 222.906 K siesta: Temp_ion = 49.991 K siesta: Temp_ion = 342.534 K siesta: Temp_ion = 555.130 K siesta: Temp_ion = 327.737 K siesta: Temp_ion = 35.523 K siesta: Temp_ion = 97.661 K siesta: Temp_ion = 453.434 K siesta: Temp_ion = 590.339 K siesta: Temp_ion = 239.125 K siesta: Temp_ion = 60.871 K siesta: Temp_ion = 482.552 K So, a question is : how to perform MD calculations with constant temperature (Nose thermostat)? Many thanks, Best wishes, Sergey
[SIESTA-L] pseudopotential for Platinum
Dear Users, Does anybody has a pseudopotential for Platinum? I cannot generate it. Thanks, Salomon __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com
Re: [SIESTA-L] Pseudopoential Generation of Cd
Dear Michael, If you got your input file from Octopus webcite, you can download a psf file of Cd pseudopotential press button ascii pseudo-potential output in Cd section. Sergey
[SIESTA-L] Denchar
Dear SIESTA users, What is software for charge density visualizing in 2D and 3D mode? Sergey
[SIESTA-L] Ge pseudopotential
Dear Siesta users, I tried to generate Ge pseudopotential. From TM-code I found an example of Ge pseudo: pe Germanium PRB 52 13283 (1995) Ecut ~ 16Ry l=0,1 (maybe 2) as local tm2n=Ge c=car 0.0 0.0 0.0 0.0 0.0 0.0 6 3 4 0 2.00 0.00 4 1 2.00 0.00 4 2 0.00 0.00 2.68 2.68 2.68 I generate a Ge.psf and Ge.vps. But I got an error with using this pseudo: initatom: Reading input for the pseudopotentials and atomic orbitals --Species number: 1 Label: Ge Atomic number: 32Ground state valence configuration: 4s02 4p02Reading pseudopotential information in formatted form from Ge.psfFor Ge, standard SIESTA heuristics set lmxkb to 3(one more than the basis l, including polarization orbitals).Use PS.lmax or PS.KBprojectors blocks to override. basis_specs===Ge Z= 32 Mass= 72.610 Charge= 0. Lmxo=1 Lmxkb=3 BasisType=split Semic=FL=0 Nsemic=0 Cnfigmx=4 n=1 nzeta=2 polorb=0 vcte: 0. rinn: 0. rcs: 0. 0. lambdas: 1. 1. L=1 Nsemic=0 Cnfigmx=4 n=1 nzeta=2 polorb=1 vcte: 0. rinn: 0. rcs: 0. 0. lambdas: 1. 1. ---L=0 Nkbl=1 erefs: 0.17977+309L=1 Nkbl=1 erefs: 0.17977+309L=2 Nkbl=1 erefs: 0.17977+309L=3 Nkbl=1 erefs: 0.17977+309===/basis_specs atom: Called for Ge (Z = 32)read_vps: ERROR: You must generate a pseudopotentialread_vps: ERROR: for each L up to 3Stopping Program What is wrong? Could please anybody send me a "working" Ge pseudo? Thanks, Best wishes, Sergey
Re: [SIESTA-L] What is total energy?
DEar Prof. Soler, Thank you for your reply. Bu I cannot understand: Does SIESTA calculate the real total energy? In most paper I see that authors compare total energy per atom (for example, for carbon) with experimentasl results. How did they obtain it? I checked it dor C-diamond, in the file carbpn.MDE the total energy/per atom is more bigger than experimental results. Sergey
[SIESTA-L] What is total energy?
Dear Siesta users, I did some calculations with SIESTA and have some problems with determining of total energy. In main output file the Toatal nergy on first step is -18851,99 eV on last step after full optimization : -18681,67 eV. I got, that last total energy is bigger than energy on first step. But in file my.MDE the total energy in eV on first step is -1372,160 eV, on last step -1373.0 eV. How it can be? The differencemore than in 13,5. The calculations was done for carbon system. If I suggest the total energy in file my.MDE is real, but this energy per atom is ~ 11,6 eV/atom. It is big energy. May I wrong? Thank for your comments and answers, Best wisahes, Sergey
Re: [SIESTA-L] siesta bug on the compaq alpha cluster
Dear Howard, I am also try to compile siesta on Compaq Alpha Linux machine. I have fort compiler, MPICH-GM, CXML. I met your problem with H20 (and anothers ) structures. I changed the FFLAGS on FFLAGS-DEBUG (without any optimizations). It works but bad. I do not know why. If you have some ideas, please tell me. Thanks, Sergey
