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 > >