[Wien] lapw1 divide by zero error
vielmaj at onid.orst.edu
vielmaj at onid.orst.edu
Fri Oct 28 19:42:29 CEST 2011
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
>
>
More information about the Wien
mailing list