[Wien] problem running lapw1c WIEN2k_08.1 MKL10

[Gerhard Fecher]

It was in this forum.

Just to mention, in MKL10 the new environment variable MKL_NUM_THREADS does not work either.

Actually, I have the most stable version running when compiled and linked with IFORT 10.0 (not 10.1) and MKL 9.1.
On em64t systems one can link with this combination everything with -static (including the pthread library, that has only problems on 32 bit systems).

IFORT 10.1 has still problems with optimization of lapw2.

Ciao
Gerhard

________________________________________
Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at] im Auftrag von Oleg Rubel [rubel at Physik.Uni-Marburg.de]
Gesendet: Montag, 10. März 2008 15:53
An: A Mailing list for WIEN2k users
Betreff: Re: [Wien] problem running lapw1c WIEN2k_08.1 MKL10

I also noticed that definition of the environment variable OMP_NUM_THREADS
is mandatory for MKL 10 in contrast to MKL 9. I even saw a note about that
in one of forums, but I do not remember where it was.

Did you try MPI version with MKL 10? I still have "Segmentation fault" in
my lapw1c_mpi.


Oleg Rubel

===========================
Faculty of Physics
Philipps University Marburg
Renthof 5, 35032 Marburg, Germany

On Mon, 10 Mar 2008, aurelio wrote:

> Hello,
> I have compiled WIEN2k_08.1 using intel fortran compilers version 10 and MKL10 in a Linux SUSE Linux Enterprise Server
> 10 (ia64). I have found several problems in runtime (just running lapw1c using the test_case) depending if I compile
> dynamically or statically and if I set OMP_NUM_THREADS or not. I will try to comment the cases:
>
> 1)dynamically linked with MKL10 without setting OMP_NUM_THREADS
> R_LIBS:-L/opt/cesga/intel/intel10.0/ict/mkl/10.0.011/lib/64 -Wl,--start-group -lmkl_intel_lp64 -lmkl_intel_thread
> -lmkl_core -Wl,--end-group -lguide -lpthread
> Here I get the following message
>
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>
> If I compile with the ifort options -C -traceback I am getting the following:
>
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image PC Routine Line Source
> ld-linux-ia64.so. 20000000000144D1 Unknown Unknown Unknown
> libc.so.6.1 2000000001170B00 Unknown Unknown Unknown
> libdl.so.2 2000000000F62010 Unknown Unknown Unknown
> ld-linux-ia64.so. 200000000001BF10 Unknown Unknown Unknown
> libdl.so.2 2000000000F626A0 Unknown Unknown Unknown
> libdl.so.2 2000000000F61F00 Unknown Unknown Unknown
> libmkl_intel_thre 2000000000867E80 Unknown Unknown Unknown
> libmkl_intel_thre 200000000086E2B0 Unknown Unknown Unknown
> libmkl_intel_lp64 2000000000308E70 Unknown Unknown Unknown
> lapw1c 40000000000F26B0 hamilt_ 409 hamilt_tmp_.F
> lapw1c 4000000000057A80 calkpt_ 154 calkpt_tmp_.F
> lapw1c 400000000023B250 MAIN__ 52 lapw1_tmp_.F
> lapw1c 4000000000004B10 Unknown Unknown Unknown
> libc.so.6.1 2000000000F9BC20 Unknown Unknown Unknown
> lapw1c 4000000000004940 Unknown Unknown Unknown
>
> The line 409 in the hamilt_tmp_.F contains:
> call vdsincos(j_end_1(ihelp),help1,help_sin,help_cos)
>
> If I set OMP_NUM_THREADS=1 the program runs without a problem.
>
> 2)statically linked with MKL10
> R_LIBS:-Wl,--start-group /opt/cesga/intel/intel10.0/ict/mkl/10.0.011/lib/64/libmkl_intel_lp64.a
> /opt/cesga/intel/intel10.0/ict/mkl/10.0.011/lib/64/libmkl_intel_thread.a
> /opt/cesga/intel/intel10.0/ict/mkl/10.0.011/lib/64/libmkl_core.a -Wl,--end-group -lguide -lpthread
>
> Without setting OMP_NUM_THREADS the programs runs using several threads chosen dynamically by the mkl library (as many
> as processors available) and at the end I am getting a message:
> Aborted
>
> Setting OMP_NUM_THREADS=1 the program works without any problem
>
> If I run the statically MKL linked version compiled with -C -traceback, I am getting the following error indepently if I
> set or not OMP_NUM_THREADS:
>
> forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable BL when it is not allocated
>
> Image              PC                Routine            Line        Source
> lapw1c             4000000000719550  Unknown               Unknown  Unknown
> lapw1c             4000000000717060  Unknown               Unknown  Unknown
> lapw1c             400000000068FB50  Unknown               Unknown  Unknown
> lapw1c             400000000061BC10  Unknown               Unknown  Unknown
> lapw1c             400000000061A1F0  Unknown               Unknown  Unknown
> lapw1c             40000000001ED530  hns_                      277  hns_tmp_.F
> lapw1c             4000000000058F70  calkpt_                   169  calkpt_tmp_.F
> lapw1c             400000000023A610  MAIN__                     52  lapw1_tmp_.F
> lapw1c             4000000000003ED0  Unknown               Unknown  Unknown
> libc.so.6.1        200000000056FC20  Unknown               Unknown  Unknown
> lapw1c             4000000000003D00  Unknown               Unknown  Unknown
>
> if I look into the  hns_tmp_.F file around line 277:
>
>                               ALMI(IHELP,L0M0,iset) = RHOATM*DIMAG(CIL*PHS(Ihelp,iset)*DCONJG(YL(L0M0,IHELP,iset)))
>                               BLMR(IHELP,L0M0,iset) = BL(Ihelp,L0,iset)*ALMR(IHELP,L0M0,iset)
>                               BLMI(IHELP,L0M0,iset) = BL(Ihelp,L0,iset)*ALMI(IHELP,L0M0,iset)
>                               ALMR(IHELP,L0M0,iset) = AL(Ihelp,L0,iset)*ALMR(IHELP,L0M0,iset)
>
> is it possible that BL were not allocated at that time?
>
> Any clues about what it is happening?
>
> Thanks in advance for your help
>
> Aurelio Rodríguez
>
>
> --
> __________________________________
> Manuel Aurelio Rodriguez Lopez
> Tecnico de Aplicaciones
> CESGA
> Avda. de Vigo s/n. Campus Sur
> 15705 - Santiago de Compostela.
> SPAIN
> Tel.: +34 981 56 98 10 Ext 244
> Fax: +34 981 59 46 16
> e-mail: aurelio at cesga.es
> __________________________________
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>