I did try to force the ifort svml library and the same error remains. The installation is exactly like I did a year ago and it worked. The only difference is this installation is on the new Ubuntu 11.10 and the old one was on Debian Squeeze. I decided to leave out the svml library, since everyone who uses it is only looking for bandstructures and DOS for simple systems.
Thanks, Jason Quoting Gerhard Fecher <fecher at uni-mainz.de>: > I remember that some older Versions of the compiler needed > explicitely the path to the vsml library for "-DINTEL_VML" > for example: > LDFLAGS:-L/opt/intel/Compiler/11.0/083/lib/intel64 -lsvml -lguide -lpthread > (note that the path in the LDFLAGS is to the compiler not to the mkl > libraries) > independent of ifort/mkl versions, this helped always. > The problem may be how ifort passes the commands to the linker, or > the linker itself. > > (Note the limitations by the pthread library of 32 bit versions of > Linux that might cause segmentation faults when linked static) > in that case you may try something like: > -L/opt/intel/fc/lib -i-static -Bstatic -lguide -lsvml -Bdynamic -lpthread > -L/opt/intel/mkl/lib/32 -Bstatic -lmkl_lapack -lmkl_ia32 -lguide > -Bdynamic -lpthread > to link only pthread dynamically.) > > Ciao > Gerhard > > DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy: > "I think the problem, to be quite honest with you, > is that you have never actually known what the question is." > > ==================================== > Dr. Gerhard H. Fecher > Institut of Inorganic and Analytical Chemistry > Johannes Gutenberg - University > 55099 Mainz > ________________________________________ > Von: wien-bounces at zeus.theochem.tuwien.ac.at > [wien-bounces at zeus.theochem.tuwien.ac.at]" im Auftrag von > "Laurence Marks [L-marks at northwestern.edu] > Gesendet: Freitag, 28. Oktober 2011 01:39 > Bis: A Mailing list for WIEN2k users > Betreff: Re: [Wien] lapw1 divide by zero error > > I am pretty sure that you have now isolated the problem to the libsvml > that you are using. The quickest method (for you) is to remove it from > the options then recompile everything, I think there are a few other > (not many) codes that use the Intel vector library. It will make the > code slightly slower, but not overwhelmingly so. > > Personally, I would want to determine the issue better. If you are > using dynamic linking then "ldd $WIENROOT/lapw1" will tell you which > version of libsvml is being linked in. (If you are running on remote > nodes you need to ssh or whatever and check there as well.) You can > force dynamic linking by removing any -i-static (or similar) > compilation options. You "should" be using one which is somewhere in > the PATH for ifort, rather than an mkl version. > > N.B., I don't know if you installed the ifort/mkl or someone else did. > It is not unusual to have incompatible combinations and many codes do > not care, but WIen2k is a good debugger of misconfigured systems. If > someone else installed the compilers you may want to talk to them > about updating. > > On Thu, Oct 27, 2011 at 6:27 PM, <vielmaj at onid.orst.edu> wrote: >> I tried removing the "-DINTEL_VML" and it now the scf cycle works just fine. >> Should I leave it like this, or should I re-compile the whole thing without >> "-DINTEL_VML". Or should I do something different. >> >> Thanks, >> >> Jason >> >> Quoting Laurence Marks <L-marks at northwestern.edu>: >> >>> The changes you made "should" not matter, since you changed the >>> complex version and TiC (and line 384) are for the real version. Two >>> thoughts: >>> >>> a) Download a clean version of SRC_lapw1 from the website, unzip/untar >>> it and do a sdiff of hamilt.F to ensure that you have changed nothing >>> else by mistake. >>> >>> b) Remove "-DINTEL_VML" from your compilation options (just for lapw1) >>> and recompile then test. If this works then you have a bad libsvml >>> and/or incompatible versions/ifort or similar. You might be picking up >>> the version from mkl rather than ifort, check the order in the linking >>> or how you are setting up, e.g. via sourcing the sh/csh compiler >>> scripts. >>> >>> If neither of these helps, I would suspect something wrong in your >>> input files -- try one of the other examples. >>> >>> N.B., I assume that you have turned on some debug options for initial >>> testing, which is wise but you will want to remove them later. >>> >>> On Thu, Oct 27, 2011 at 5:34 PM, <vielmaj at onid.orst.edu> wrote: >>>> >>>> Hello, >>>> >>>> I am getting a divide by zero error in the lapw1 routines. >>>> >>>> I compiled with the ifort 10 and mkl 9 compilers. To compile completely >>>> with no errors, I had to make the following changes n SRC_lapw1/hamilt.F >>>> program below for me using an older compiler. >>>> >>>> ! in case of older mk/vml you may miss vzcis (IPO Error: unresolved : >>>> vzcis_) >>>> ! Either upgrade the libraries (ifort+mkl) or: >>>> ! Comment the line below and uncomment the other ones. >>>> ! Uncomment also all other lines above where help_tmpcos occurs >>>> >>>> !!_COMPLEX call vzcis(j_end(ihelp),help1,help_exp) >>>> !_COMPLEX call vdcos(j_end(ihelp),help1,help_tmpcos) >>>> !_COMPLEX call vdsin(j_end(ihelp),help1,help_tmpsin) >>>> !_COMPLEX do j = 1, j_end(ihelp) >>>> !_COMPLEX help_exp(j) = dcmplx(help_tmpcos(j),help_tmpsin(j)) >>>> !_COMPLEX end do >>>> >>>> #these three lines below are also in hamilt.F that were uncommented >>>> !_COMPLEX deallocate( help_tmpcos, help_tmpsin ) >>>> !_COMPLEX DOUBLE PRECISION, allocatable :: help_tmpsin(:), >>>> help_tmpcos(:) >>>> !_COMPLEX allocate( help_tmpcos(HSdim_r), help_tmpsin(HSdim_r) ) >>>> >>>> Once I run the TiC example, I get this error. >>>> >>>> hup: Command not found. >>>> Invalid null command. >>>> LAPW0 END >>>> Invalid null command. >>>> forrtl: severe (71): integer divide by zero >>>> Image PC Routine Line >>>> Source >>>> lapw1 000000000049B8F2 Unknown Unknown >>>> Unknown >>>> lapw1 000000000049BAF0 Unknown Unknown >>>> Unknown >>>> lapw1 00000000004932D4 Unknown Unknown >>>> Unknown >>>> lapw1 000000000042D547 hamilt_ 384 >>>> hamilt_tmp_.F >>>> lapw1 000000000041CC99 calkpt_ 156 >>>> calkpt_tmp_.F >>>> lapw1 000000000044A312 MAIN__ 61 >>>> lapw1_tmp_.F >>>> lapw1 0000000000413B4E Unknown Unknown >>>> Unknown >>>> libc.so.6 00002B735713A30D Unknown Unknown >>>> Unknown >>>> lapw1 0000000000413A69 Unknown Unknown >>>> Unknown >>>> >>>>> stop error >>>> >>>> >>>> It links to the following line in the hamilt.F program. >>>> >>>> !_REAL call vdcos(j_end(ihelp),help1,help_cos) >>>> >>>> Thanks for you help, >>>> >>>> Jason Vielma >>>> _______________________________________________ >>>> Wien mailing list >>>> Wien at zeus.theochem.tuwien.ac.at >>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >>>> >>> >>> >>> >>> -- >>> Laurence Marks >>> Department of Materials Science and Engineering >>> Northwestern University >>> www.numis.northwestern.edu >>> "Research is to see what everybody else has seen, and to think what >>> nobody else has thought" >>> Albert Szent-Gyorgi >>> _______________________________________________ >>> Wien mailing list >>> Wien at zeus.theochem.tuwien.ac.at >>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >>> >> >> _______________________________________________ >> Wien mailing list >> Wien at zeus.theochem.tuwien.ac.at >> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >> > > > > -- > Laurence Marks > Department of Materials Science and Engineering > Northwestern University > www.numis.northwestern.edu > "Research is to see what everybody else has seen, and to think what > nobody else has thought" > Albert Szent-Gyorgi > _______________________________________________ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > _______________________________________________ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > >
